电脑版给自家应用换服务器地址：需求、附件与验证

这篇教程只讨论一件事：把你自己的、你团队的、或者已经拿到书面授权的应用，里面的服务器地址从测试环境切换到正式环境，或者从外网地址切换到内网地址。它不涉及去限制、去广告、破解付费内容，也不涉及任何第三方商业应用的改造。道理很简单：只有你拥有代码和后台，你才知道旧地址为什么存在、新地址能不能扛住、出问题谁来兜底。

很多同学对“换服务器地址”的想象，是在某个文件里找到一行 http 开头的字符串，删掉，粘贴新的，保存，重新打包。真正上手会发现三件事同时发生：第一，同一个域名在工程里出现七八次，有的在字符串资源里，有的在 assets 的 JSON 里，有的藏在 so 库；第二，改完能装上，但登录不上，因为后台不认新的签名；第三，昨天测试环境还好好的，今天正式环境换了证书，应用直接握手失败。所以这件事的本质不是“改字符串”，而是“让客户端在新环境里完成一次可信的身份迁移”。

本文用的工具是智能修改电脑版：Windows 10/11 64 位，需要 .NET Framework 4.6.2 以上，安装包约 6.86 MB。把 APK 拖进去，它会自动反编译，按你写的自然语言需求修改代码与资源，然后回编、对齐、签名、校验，还能直接装到手机或模拟器上预览。它负责“动手”，你负责两件更关键的事：把需求说清楚，把结果验明白。

为了让流程可复现，本文会把动作拆成八步：确认地址层级、备份、写需求、给附件、让 AI 修改、回编对齐签名、安装验证、失败排查。每一步都给出可直接照做的清单和判断标准。两个实例分别是自家记账 App 从测试 API 切到正式 API，以及自家内部巡检工具从外网地址切到内网地址，每个都写清“以前怎么做、现在怎么做、改完怎么验证”。

一、先把边界划清：换地址到底在换什么

一个地址不是一个孤立的字符串，它至少包含五个部分：协议、主机、端口、路径、参数。这五部分里任何一处变化，客户端的反应都可能不同。协议从 https 换成 http，Android 高版本默认就拦；主机从域名换成 IP，证书校验立刻失败；端口从 443 换成 8443，防火墙和证书 SAN 都要跟着改；路径从 /v1 换成 /api/v1，网关路由和鉴权规则要一起动；参数里的 appid、channel、env 变了，后台可能把你当成另一个租户。

所以在动手之前，先回答三个问题。第一，这个地址是谁在用？是自家业务接口、自家图片服务、自家 WebSocket，还是第三方统计、推送、支付、地图的地址？只有自家的才改，第三方的地址动了就是事故。第二，这次切换到哪个环境？测试、预发、正式、内网，是四套完全不同的配置，名字像不代表配置像。第三，出问题多久能退回去？原包还在不在、旧环境还开不开、签名证书是不是同一张，这三件事决定了你的回退窗口。

判断标准很朴素：如果你说不清“这个域名归谁维护、切换后谁负责验证、失败后怎么退回”，那就还没到可以改包的时候。先把这三个问题在群里问清楚，比改十次包都省时间。

还有一个容易被忽略的事实：重新签名会改变证书指纹。同一份代码、同一个包名，用不同证书签出来，在系统眼里就是两个应用。覆盖安装会失败，必须先卸载；而后台如果做了签名校验，比如开放平台、推送、支付、自家风控里的证书白名单，新包会被直接拒绝。这不是改包出错，而是身份变了。解决办法只有两个：要么用公司原有的 JKS/keystore 签名，保持指纹不变；要么把新指纹提前报备给后台。前者更省事，后者要协调。本文后面会反复提到这一点。

再补一个边界：不要为了“让新环境能连上”去关闭客户端的证书校验、不要绕过域名白名单、不要把 HTTPS 降级成 HTTP。这些都是安全底线，改了确实能连上，但等于把自家应用的门锁拆了。正确做法是让运维把证书配好、把内部 CA 下发到设备、把新域名加进白名单。改包只能改配置，不能改安全策略。

二、第一步：确认地址写在哪个层

同样叫“服务器地址”，在 Android 工程里可能藏在五个不同的层。层的不同，决定了改法、风险和回退难度。先定位再动手，是整篇文章最重要的一条纪律。下面这张表可以先收藏，排错时逐行对照。

层级	典型位置	怎么确认	改动风险
常量层	smali 里的 const-string、构建配置生成的常量类	搜索旧域名，看是否被传给网络库	低，替换直观
资源层	res/values/strings.xml、arrays.xml 及多语言副本	搜索 res/values* 全部目录	中，容易漏副本
配置文件层	assets 下的 json/ini/properties、res/raw 下的文件	按扩展名与目录逐个打开	中，注意编码与格式
so 层	lib 下各 ABI 的 .so 动态库	用文本扫描工具在二进制里找可读域名	高，不要硬改
远端配置层	启动后从配置中心/CDN 拉取的配置	抓启动请求，或找 config 拉取逻辑	最低，改服务端即可

先说怎么搜。在电脑版里导入 APK 后，每个项目会生成一个 8 位随机名的目录，里面包含 source.apk、config.ini、history.ini，以及 apktool 反编译出来的工程。你可以直接在资源管理器里打开这个项目目录，用系统搜索或命令行做全文检索。最稳的是在项目根目录打开命令行，执行 findstr /s /i /n "api-test.example.com" *.*，把所有命中位置和行号列出来。注意把示例域名换成你自己的旧域名，不要带协议头，只搜主机名，命中率最高。

常量层的特征是“改一处就生效，但容易改到无关的地方”。反编译之后，Kotlin 或 Java 里定义的静态常量会变成 smali 中的 const-string 指令，构建配置生成的常量类也会以普通类的形式出现。搜索旧域名时，你会同时命中真正的接口地址、日志前缀、错误提示文案、甚至注释。判断方法不是看字符串长得像不像，而是看它有没有被传进网络请求：往上找调用链，看它是否出现在 OkHttp、Retrofit、HttpURLConnection、WebView.loadUrl 这类入口附近。只改文案不改调用点，等于白改；只改调用点漏了拼接前缀，等于半通。

资源层的坑在多语言副本。很多项目把 base_url 放在 res/values/strings.xml，同时又有一份 res/values-en/strings.xml、res/values-zh-rCN/strings.xml。你改了默认 values，手机语言恰好命中英文目录，读到的还是旧地址。表面现象是“明明改了却没生效”，实际是资源覆盖顺序在作怪。所以搜索时不要只搜 values，要搜 values 开头的所有目录；改的时候要么全部同步，要么确认测试设备的语言只命中你改的那一份。资源层还有一个特点：字符串里的 & 需要转义，URL 里带查询参数时尤其容易出错，改完要打开文件核对一遍原文。

配置文件层的坑在编码和格式。assets 下的文件不参与编译，原样打进 APK，常见的有 config.json、settings.ini、env.properties；res/raw 下的文件会被编译成资源 ID，读取方式不同但内容一样。打开之前先确认编码，UTF-8 无 BOM 最稳，带 BOM 的 JSON 在某些解析器里会直接报错。改的时候只动值，不动键名、不动缩进结构、不删逗号。如果 assets 里的文件是加密的或者压缩成 .dat，搜索不到明文，这时候不要猜，去找研发要明文配置或者解密入口，否则你改的不是运行时真正读到的那份。

so 层要特别克制。有些 SDK 或者核心模块把域名编译进了 lib 下的 .so，用文本扫描能在二进制里看到可读的 ASCII 域名。看到之后第一反应不该是“改掉它”。二进制里的字符串长度是编译期固定的，你换一个长度不同的域名，轻则功能异常，重则整个库加载失败；即使长度相同，也可能破坏偏移和校验。正确做法是：如果地址在 so 里，先判断有没有上层覆盖入口，比如初始化时传入的 baseUrl、配置中心下发的字段；有就走上层，没有就让研发重新编译 so，或者把地址改成可配置参数。AI 改包很强，但它不该被用来硬改二进制。知道什么时候停手，是这套流程里最专业的部分。

远端配置层是最理想的落点。不少应用启动后会先请求一个配置接口，拿到接口域名、开关、灰度比例，再初始化业务网络库。这种情况下，客户端的地址只是“配置入口”，真正的业务地址在服务端。切换环境时，改服务端配置就能完成，客户端一行都不用动，回退也只是把配置改回去。判断方法是抓一次冷启动的请求，看第一个或前几个请求里有没有 config、setting、init 之类的路径；或者看代码里有没有在启动阶段解析 JSON 并写入本地缓存的逻辑。如果能走这条路，优先走这条路。

定位的优先顺序建议是：远端配置优先于配置文件，配置文件优先于资源，资源优先于常量，常量优先于 so。越靠外，改动越安全，回退越容易。反过来说，如果你一上来就改常量，改完发现被远端配置覆盖了，白忙一场；如果一上来就动 so，可能连应用都起不来。

三、第二步：备份，让任何一步都能退回去

改包这件事，成功路径只有一条，失败路径有几十条。备份不是为了仪式感，而是为了在验证失败时把时间成本压到最低。一次完整备份只需要几分钟，一次没有备份的返工可能要重走反编译、定位、改值、打包、装机全流程。下面四样东西，建议在点“立刻修改”之前全部准备好。

备份对象	怎么备	为什么必须备
原始 APK	单独目录保存，文件名带版本、环境、日期、签名状态	回退时直接装回，不依赖任何工具链
项目目录	整个 8 位随机目录复制一份，含 source.apk、config.ini、history.ini 与 apktool 工程	改坏了可以整目录还原，不用重新导入
配置快照	把旧地址所在的文件完整复制，文件名加 .bak 与日期	只记地址不够，键名和上下文才是还原依据
变更台账	一行一条记录：应用、包名、环境、键名、旧值、新值、证书、验证人、日期、回退方式	团队协作时，它是唯一可信的“改过什么”的记录

命名的建议是“谁、什么版本、什么环境、什么状态、什么时候”。例如自家记账 App 的正式包可以叫 Ledger_3.2.1_prod_20261022_signed.apk，测试包叫 Ledger_3.2.1_test_20261022_signed.apk。不要用“最终版”“最终版2”“真的最终版”这种命名，过一周你自己都分不清哪个是能回退的那一个。原始包和改过的包要分目录放，避免文件名相同被覆盖。

版本号也要顺手处理。改完的包建议把 versionName 加一个环境后缀，比如 3.2.1-prodtest，这样在设备的应用信息里一眼就能看出装的是哪一版。但要注意，有些后台会校验版本号，有些应用市场会拒绝非标准版本号，所以这一步要提前和目标环境确认。versionCode 一般不动，动了会影响升级判断。如果只是为了区分，改 versionName 就够了。

回退方案要写成三句话。第一句：原包在哪里，能不能直接装回去。第二句：旧环境还开着吗，会不会在你验证的这两小时里被下线。第三句：如果新包已经发给了同事，怎么让他们退回旧包。这三句话写不出来，说明回退方案还停留在“应该没问题”的阶段。真正可靠的切换，是旧环境保留至少一个观察周期，新包先在小范围安装，确认登录、接口、HTTPS、超时都正常，再逐步扩大。

一个很现实的提醒：改了签名的包不能覆盖安装，必须先卸载旧版，而卸载会清掉本地数据。如果这个应用里有未同步的草稿、离线缓存、登录态，切换前一定要让使用者先同步或导出。别把“换个地址”做成“丢一次数据”。

如果你打算用公司原有的 JKS 或 keystore 签名，提前确认三件事：证书文件在谁手里、口令怎么传递、证书有效期还剩多久。电脑版支持默认签名、JKS/keystore、PEM 加 PK8、随机签名四种方式，签名方案支持 v1、v2、v3、v4，默认是 v1+v2+v3。正式环境切换建议用公司证书，指纹不变，后台白名单、开放平台、推送、支付都不用改；随机签名只适合内部测试，装到别人手机上会出现覆盖安装失败。口令通过环境变量传入，不拼进命令行，也不会写进日志，这一点在团队协作时尤其重要。

四、第三步：把需求写成“四要素”

智能修改电脑版的输入方式很直接：在详情页的输入框里写人话，点“立刻修改”，需求就会被送进右侧的 AI 工作区执行。它不要求你懂 smali，也不要求你会写正则，但它要求你把话说到位。同样一句“把服务器地址改成正式的”，人听了会追问，机器听了只能猜；猜错一次，就是一轮返工。所以写需求这件事，值得单独用一节来讲。

我把好用的需求拆成四个要素：改哪里、从什么改成什么、不许动什么、改完怎么算成功。四件事写全，需求通常在两百到四百字之间；缺一件，AI 就会在缺失的地方自行补全，而它的补全逻辑和你的业务逻辑不一定一致。

要素	要写什么	常见反例	正确写法
改哪里	文件、键名、层级；不确定时写“请先定位再改，只改运行时使用的那一处”	“把接口地址改一下”	“res/values/strings.xml 里的 api_base_url”
旧值到新值	逐字给出，含协议、主机、端口、路径、结尾斜杠	“换成正式域名”	“https://api-test.own.com/v1 改为 https://api.own.com/v1”
不许动什么	第三方域名、其他环境地址、业务逻辑、证书校验、超时以外的参数	只字不提边界	“统计、推送、支付、地图域名都不要动”
验收与回退	启动、登录、列表、上传、HTTPS、超时；旧值副本保留方式	“改完能打开就行”	“登录成功、订单列表能加载、上传成功、证书校验通过”

第一个要素是位置。位置写得越具体，AI 的搜索范围越小，越不容易误伤。你可以写文件名加键名，也可以写“在 strings 资源里搜索 api-test 这个主机名，只改命中的那一条”。如果你自己还没定位清楚，也可以把定位工作交给 AI，但要在需求里明确“先列出所有命中位置，再改运行时使用的那一处，不要批量替换”。批量替换是这类任务里最危险的动作，因为同一个域名可能出现在错误提示、日志、分享文案里，全改会让界面出现奇怪的文字，甚至让日志脱敏失效。

第二个要素是值，必须逐字。不要写“测试地址换成正式地址”，要写完整的旧值和新值。协议是 http 还是 https，主机是域名还是 IP，端口是默认还是显式，路径带不带 /v1，结尾有没有斜杠，这些都要写。斜杠的问题特别常见：旧值是 https://api.own.com/v1，新值写成 https://api.own.com/v1/，代码里再拼一个 /user/login，最终请求就变成 /v1//user/login，有的网关会 404，有的会 301，有的干脆返回空。还有一种情况是旧值本身没有路径，新环境要求带路径，这种必须在需求里点明“新值包含路径，不要在代码里额外拼接”。

写 URL 的时候，前后留空格或换行，不要紧贴中文标点。很多事故不是出在值本身，而是出在值后面跟了一个全角句号、一个中文引号，或者复制时带进来的零宽字符。最稳妥的格式是单独一行写“旧值：”换行写地址，再换行写“新值：”换行写地址。这样既方便人核对，也方便 AI 精确提取。

第三个要素是边界，核心是“只改自家域名”。一个稍微成规模的应用，通常同时连着这些地址：自家业务接口、自家上传服务、自家 WebSocket、自家图片 CDN、自家内嵌 H5、第三方统计、第三方推送、第三方支付、第三方地图、第三方分享、应用市场更新检查。这次切换只应该动前五个里确实需要动的那几个，后面五个一律不碰。第三方 SDK 的地址往往和 key、包名、签名绑定，你改了域名，SDK 初始化就会失败，表现为推送收不到、支付拉不起、地图白屏，而这些问题很容易被误判成“地址没改对”。

边界还要写清“不改逻辑”。换环境时最容易被顺手改掉的是超时时间、重试次数、日志级别、缓存开关。这些参数确实会影响体验，但它们属于另一类变更，应该单独提需求、单独验证。把地址和超时混在一次修改里，出问题时你无法判断是域名解析慢还是超时设得太短。同理，不要在同一轮里改包名、改应用名、换图标，变量太多，验证就没有意义。

第四个要素是验收与回退。验收要写成可观察的现象，而不是“正常”“没问题”这种感受词。比如“冷启动两次不闪退”“账号密码登录返回 200 并进入首页”“订单列表首屏 3 秒内出现”“上传一张 5 MB 图片成功”“HTTPS 证书校验不报错”“断网时 10 秒内出现重试提示而不是白屏”。回退要写清旧值副本放在哪里、是否参与运行。这里有个细节：如果你让 AI“保留旧地址作为备用，失败自动切回”，那验证结果就不可信了，因为你不知道当前连的是新环境还是旧环境。正确做法是保留副本但不参与运行，需要回退时人工换回。

需求模板可以直接抄下面这段，把方括号里的内容换成你自己的。它的好处是：即使过两周回头看 history，你也能一眼看出当时改的是哪个键、从哪改到哪、边界在哪。

项目：自家记账 App，包名 com.own.ledger，版本 3.2.1。
目标：把测试环境接口切换到正式环境，只改自家接口域名。
位置：res/values/strings.xml 中的 api_base_url；assets/app_config.json 中的 api.base。
旧值：https://api-test.own.example.com/v1
新值：https://api.own.example.com/v1
要求：两处一起改，路径 /v1 保留，结尾不要加斜杠；
第三方统计、推送、支付、地图、分享的域名一律不要动；
不要修改证书校验逻辑，不要改超时时间，不要改业务代码。
保留：把旧值原样写入 assets/app_config.rollback.json，仅作记录，不参与运行。
验收：冷启动不闪退；账号登录成功；账单列表能加载；上传凭证成功；
HTTPS 不报证书错误；断网时能出现明确提示。

对比一下反例：“帮我改一下服务器地址，改成正式的，谢谢。”这句话里没有任何可执行信息：哪个文件、哪个键、旧值是什么、新值是什么、哪些不能动、怎么算成功，全是空白。AI 只能靠搜索猜测，猜中了你觉得它聪明，猜错了你觉得它不行，其实是需求没写清。详情页里内置了三千条话术，按界面美化、弹窗引流、去除限制、常规修改、混淆去毒、插件添加六类组织，点一条就能填进输入框。话术适合做骨架，但环境切换这种精确任务，建议在骨架基础上自己补齐四要素，尤其是旧值和新值。

五、第四步：附件怎么给，history 为什么只留原话

文字需求解决“要什么”，附件解决“长什么样”。环境切换涉及大量对照关系：旧域名对应新域名、测试库对应正式库、内网端口对应服务、证书对应域名。这些信息写成文字容易串行，做成表格加截图，一眼就能核对。电脑版的附件系统支持一次多选文件，每个文件都要写用途说明，而且说明不能少于十个字。

这个“十个字”不是为了刁难人，而是为了让附件可追溯。你 attach 了五张截图，如果只写“截图”“配置”“参考”，过一天你自己都分不清哪张是正式环境、哪张是测试环境。写清用途之后，附件会按“序号、路径、说明”的形式随需求一起发出，AI 能根据说明判断哪张图对应哪个值，你回头查记录也能对上号。附件在加入时会做四项校验：文件存在、不是目录、不是 0 字节、可读。用快捷方式、云盘占位文件、正在被占用的文件，都可能在这一步被拦下来，换成真实文件即可。

附件类型	用途说明示例（均超过 10 字）	注意点
接口对照表	正式环境接口地址对照表，第二行是本次要改的 base_url	用 CSV 或表格截图，旧值新值分两列
后台配置截图	正式环境后台域名白名单配置页截图，含已备案域名列表	截全窗口，保留地址栏与页面标题
内网端口表	内网服务端口对照表，标注网关、上传、文件服务三个端口	按公司规定脱敏，不要带生产口令
旧配置文件	旧版 assets 配置文件原件，用于核对键名与缩进格式	保留原编码，不要用记事本另存改变格式
报错截图	切换后登录失败的报错截图，包含错误码与请求地址	截图要包含时间和应用版本，方便对齐

附件不是越多越好。一次给五到八个文件足够，重点是让每个文件都有明确用途。给十几张重复截图，反而会稀释关键信息。截图的原则是“截全、截清、截关键”：全窗口比局部截图可靠，因为局部截图容易漏掉地址栏和域名；清晰比压缩重要，糊掉的证书指纹等于没给；关键信息要圈出来，但不要用大面积涂鸦盖住结构，否则 AI 无法判断字段关系。涉及账号、token、手机号、身份证号的内容必须打码，打码也要保留字段长度和位置关系。

然后是一个很多人忽略的机制：history 只留原话。点“立刻修改”之后，你在输入框里写的那段原文和日期会写进项目的 history.ini，而 AI 在工作区里的分析、改写、执行过程不会写进去。这意味着 history 是一本“你说过什么”的账本，不是“改了什么”的账本。它的价值在于复现：下次遇到同类切换，点历史里的“选择”就能把原话填回输入框，改几个值再发一次。

理解了这个机制，写法就要跟着调整。第一，一次把话说完，不要分三次发“先改 A”“再改 B”“刚才那个也改一下”，因为 history 只会留下三段互相独立的话，回头看根本串不起来。第二，不要用指代，比如“同上”“按刚才说的”“那个地址”，history 里没有上下文，三天后你也想不起“那个”是哪个。第三，补充要求要么重新组织成一段完整需求再点一次，要么在工作区里继续沟通，但要知道 history 里仍然只有最初那段原话。第四，重要信息（旧值、新值、边界）必须出现在原话里，不能只放在附件说明里，因为附件说明是随需求发出的，而 history 只存原话。

把 history 当成“需求模板库”来用，而不是当成“变更记录”来用。变更记录要靠你自己那张台账；history 负责让你在下一次少打两百个字。

详情页的历史是最新在上，显示完整原文，右侧有“选择”可以回填。项目列表里也能看历史、删除项目，删除只允许删 Project 的直接子目录，这个限制是为了避免误删工作目录里的工具链。如果你同时维护测试包和正式包，建议建两个项目，而不是在一个项目里反复改，这样 history 和 source.apk 都不会混。

六、第五步：让 AI 改，然后把打包四步看明白

需求写完、附件挂好，点“立刻修改”。这一下会发生几件事：你的原文和日期写进 history.ini；需求被送进右侧的 AI 工作区执行；AI 改完 apktool 工程后，在项目目录里留下一个 ai_done.flag；主窗口每 2 秒轮询一次，读到这个文件就删掉，然后进入打包环节；整个等待有一个上限，一小时。了解这个节奏，你就不会在等待期间反复点按钮，也不会误以为程序卡死。

等待的这段时间不要闲着。把验证清单准备好：测试账号、测试数据、抓包工具、目标设备、回退包。账号要确认能登录，数据要确认列表非空，设备要确认已开调试并且 ABI 匹配，回退包要放在随手能拿到的地方。很多验证失败不是改错了，而是测试账号本身过期、测试环境数据为空、设备存储满了装不上。先把这些外围因素排掉，再看改包结果。

如果超过一小时还没有结果，或者中途报错，先看两个日志：项目目录下的 apktool.log 记录反编译输出，工作目录下的 error.log 记录未处理异常。常见原因是需求太宽泛导致 AI 反复搜索、工程太大导致反编译超时、或者原包里本身有损坏的资源。处理办法是把需求拆小：第一轮只让它定位并列出所有命中位置，第二轮只改确定的那一处，第三轮再处理第二个文件。分轮执行虽然多一次操作，但每一轮都可验证，比一次性大改更稳。

AI 完成后，工具会自动走完打包四步。你不需要手动敲命令，但必须知道每一步在做什么，因为出问题时日志里的报错就对应这四步。下面这张表建议打印出来贴在显示器旁边。

序	动作	作用	失败先看什么
1	apktool b -f -o build\unsigned.apk	把改过的工程回编成未签名 APK，-f 表示覆盖旧产物	apktool.log 里的资源错误、9patch 警告
2	zipalign -f -p 4	按 4 字节边界对齐，-p 处理 so 的页对齐，减少运行内存开销	对齐失败通常是输入文件不是合法 APK
3	apksigner sign	按选定证书签名，默认 v1+v2+v3	密钥格式、别名、口令、证书链
4	apksigner verify --print-certs	确认签名真的写进去了，并打印证书信息	verify 报错说明前一步没签成功

四步里最容易被跳过的是第四步：verify。很多人的习惯是签完就装，装上了就认为签名没问题。但在正式环境里，“签上了”和“签对了”是两件事。签名工具在密钥格式不标准、证书链不完整、别名写错的情况下，有时会给出一个看起来成功的结果，只有 verify 会明确报出问题。多跑一条命令，换来的是“到底签没签上”的确定答案，以及一份可以和白名单核对的证书信息。这就是为什么打包流程要坚持四步，而不是三步。

顺序也不能乱。对齐必须在签名之前，因为 v2 签名会对整个文件做完整性校验，你先签名再对齐，对齐动过的字节会让签名失效，装到设备上就是“安装包解析失败”或者“签名校验不通过”。回编必须在对齐之前，因为对齐只处理压缩包的字节边界，不处理资源。签名必须在 verify 之前，这个不用解释。四步是一条单向流水线，任何一步回头都会让后面的结果作废。

pack.log 是这条流水线的黑匣子。整个过程都会写进这个文件：每一步的起止、命令参数、工具输出、错误码、最终产物路径、证书信息。排查时按顺序看：先确认四步是否都出现，缺哪步就是哪步之前中断了；再看每一步的返回结果，非零退出码就是失败点；然后看错误文本里的关键词，资源错误找 apktool.log，签名错误找证书和口令，对齐错误找输入文件；最后看证书指纹，和后台白名单逐位核对。不要一上来就全文搜索“error”，因为工具的正常输出里也可能出现这个词，按阶段看更准。

签名方式有四种：默认签名、JKS/keystore、PEM 加 PK8、随机签名。正式环境切换建议用 JKS/keystore，因为它是公司长期维护的证书，指纹稳定，后台白名单不用改。PEM 加 PK8 适合从其他工具链迁移过来的场景。默认签名适合快速自测。随机签名每次生成新证书，只适合一次性的内部验证，千万不要用它给同事发安装包，否则下一次覆盖安装必然失败。签名方案默认 v1+v2+v3，兼容性最好；如果目标设备很老，确认 v1 是否覆盖；如果目标系统很新，v3 的密钥轮换信息也要保留。

打包完成后，工具会自动做设备预览：用 adb 找设备，装包，执行 am start -W -n 包名/Activity 拉起应用，再用 dumpsys 复核前台应用确实是它；手机通过 scrcpy 投屏到电脑，模拟器则提到最前。启动组件名有三档查找：先读 config.ini 里记录的 LaunchableActivity，找不到就用 cmd package resolve-activity --brief 解析，再不行走旧方式兜底。这套机制的好处是，你不需要记住 Activity 全名，工具会自己找。

如果没有设备，或者设备没开调试，预览会失败，但打包产物仍然在。这时候不要怀疑改包失败，先解决 adb 连接：数据线是否支持传输、驱动是否安装、设备是否授权调试、adb devices 能不能看到设备。模拟器要注意 ABI，只包含 arm64 原生库的应用，在 x86 模拟器上装不上，报错通常是 INSTALL_FAILED_NO_MATCHING_ABIS，这是环境问题，不是改包问题。换一台匹配 ABI 的设备，或者用真机，问题就消失了。

七、第六步：验证——登录、接口、HTTPS、超时，一个都不能少

装上了不等于改对了。设备预览只能证明“包能装、应用能起”，真正决定这次切换是否成功的，是四个维度：登录、接口、HTTPS、超时。少验一个，问题就会在同事手里爆发。这一节把四个维度拆成可执行的动作，照着做即可。

维度	怎么测	通过标准	失败先看哪
登录	冷启动两次、杀进程再启动、账号密码登录、退出再登录、token 刷新	不闪退，能拿到 token，401 不再出现	logcat 的状态码与响应体
接口	列表、详情、提交、上传、分页、下拉刷新；抓包看 host 与 path	全部命中新域名，返回 200，业务数据正确	请求 URL 与 404/301
HTTPS	看证书链、SAN、有效期；确认没有关闭校验；确认没有 pinning 冲突	握手成功，无证书错误，无降级	SSLHandshakeException 的具体原因
超时	弱网、断网、跨网段、上传大文件；观察首屏时间与提示	超时有明确提示，恢复网络后能重试成功	连接超时与读取超时的区分

登录要分三层看。第一层是网络层：请求有没有发出去，DNS 有没有解析到新地址，TLS 有没有握手成功。第二层是协议层：返回码是 200、401、403 还是 500，响应体里有没有 token、有没有错误码。第三层是业务层：登录后能不能拉到用户信息、权限对不对、首页数据是不是空的。很多“登录失败”其实是第二层返回了 401，而 401 的原因是后台不认新域名或者不认新签名，不是账号密码错了。看 logcat 比反复输密码有效得多。

token 刷新是一个容易被漏掉的场景。登录时拿到的 token 可能只有几十分钟有效期，刷新接口往往走另一个路径或者另一个域名。如果只改了登录域名，没改刷新域名，表现就是“刚登录正常，过一会儿全部接口 401”。验证方法很简单：登录后把应用放后台，等 token 接近过期再切回来，看能不能自动续期。不能续期就回到定位清单，找 refresh 相关的地址。

接口要逐个点，不要只点首页。首页通常只调一个聚合接口，成功率高；真正容易出问题的是上传、导出、支付回调、消息列表、分页加载。这些接口可能走不同的域名、不同的网关、不同的鉴权方式。抓包时重点看三件事：host 是不是新域名，path 有没有多斜杠或少路径，返回码是不是 2xx。抓包工具在 Android 高版本上需要安装调试证书，这件事只能在自家测试设备上做，不要拿同事的生产手机折腾。

HTTPS 要验四件事。证书链是否完整，中间证书有没有漏；SAN 是否包含新域名，只写主域名不写 www 或 api 子域是常见错误；有效期是否覆盖上线周期；证书是否由设备信任的 CA 签发。Android 7 以后，用户自己安装的 CA 默认不被应用信任，所以“浏览器能打开”不代表“应用能握手”。如果内网使用自建 CA，正确做法是由运维把 CA 下发到设备的管理配置里，或者给内网服务申请受信任的证书；不要为了让应用连上就在代码里关掉校验。证书固定（pinning）又是另一层：应用里预置了旧证书的指纹，换域名后指纹对不上，握手直接失败，这种只能由研发更新 pin 或者改成远端下发。

URL 本身也要校验。把新旧地址并排放在一起，逐字比对：协议、主机拼写、端口、路径大小写、结尾斜杠、查询参数。特别注意几种隐形错误：从聊天工具复制来的地址带了不间断空格；中文输入法把冒号打成全角；地址末尾跟了一个句号；URL 里的 & 在 XML 资源里没有转义。这些错误在编辑器里看起来一模一样，在运行时就是 UnknownHostException 或者 404。最省事的校验方法是用浏览器或命令行先请求一次新地址，确认它在应用之外是通的，再排查应用内部。

验证顺序建议固定为：能不能启动、能不能登录、核心接口通不通、HTTPS 过不过、超时表现合不合理、外围功能有没有被误伤。顺序固定下来，团队里谁去验都能得到一致结论。

超时要单独拎出来说。内网环境和外网环境的延迟特征完全不同：外网可能 80 毫秒往返，内网跨网段可能 300 毫秒，加上 VPN 还可能丢包。如果连接超时设得很短，内网首屏就会大量失败；如果设得太长，用户会盯着白屏。验证时至少覆盖三种场景：正常 Wi-Fi、弱网（限速或丢包）、断网。观察三件事：多久出现 loading、多久出现错误提示、恢复网络后能不能自动重试。好的体验是“快速失败、明确提示、可重试”，而不是“一直转圈、最后白屏”。

八、两个自家应用实例：从测试到正式，从外网到内网

下面两个实例都来自自家应用，一个是面向用户的记账 App，一个是只在内部使用的巡检工具。它们的共同点是：地址不在一个地方，验证不只看能不能打开，回退必须有明确路径。不同点是：一个主要面对公网证书，一个主要面对内网证书和端口。

实例一：自家记账 App，测试 API 切到正式 API

以前怎么做。先用反编译工具把 APK 拆开，在 smali 里全局搜 api-test 这个主机名，找到两三处 const-string，逐个改成正式域名。改完执行回编，再用对齐工具处理一遍，然后用签名工具签上，装到测试机。登录转圈，抓包发现 assets 里还有一份 JSON 也写着测试地址，于是回到工程改第二处，再回编、再对齐、再签名、再安装。这次能登录了，但上传凭证报 401，查了半天才发现是换了签名证书，后台的证书白名单里没有新指纹。找运维加白名单，等回复，再验一轮。一个晚上过去，真正改地址的时间不到十分钟，其余都花在“漏了哪里”和“为什么后台不认”上。

现在怎么做。把 APK 拖进智能修改电脑版，等它反编译完，在详情页写四要素需求：位置写到 strings.xml 的 api_base_url 和 assets/app_config.json 的 api.base；旧值和新值逐字给出，保留 /v1 路径、不加结尾斜杠；边界写明统计、推送、支付、地图、分享的域名一律不动，不改证书校验、不改超时；验收写明冷启动、登录、账单列表、上传凭证、HTTPS、断网提示六项。附件放一张接口对照表、一张后台域名白名单截图、一份旧配置文件。点“立刻修改”，等 AI 完成，工具自动回编、对齐、签名、verify，然后装到测试机预览。整个过程里，人只做三件事：写清需求、核对附件、按清单验证。

改完怎么验证。第一步看应用信息，确认版本号和签名指纹与台账一致；第二步冷启动两次，确认不闪退；第三步用测试账号登录，抓包确认 host 已经是 api.own.example.com，路径是 /v1/auth/login，返回 200；第四步进账单列表，下拉刷新，翻到第二页，确认分页参数正常；第五步上传一张凭证图片，确认走的是新上传域名；第六步把 Wi-Fi 关掉再打开，确认超时提示出现且能重试；第七步等 token 接近过期，切后台再切回，确认自动续期。七步都过，才算这次切换完成。

实例二：自家内部巡检工具，外网地址切到内网地址

以前怎么做。这个工具只在办公网用，原来连的是外网测试域名。要切到内网，先得把 APK 拷进隔离环境，用内网签名机重新签，改 assets 里的 config.json，把 https://ops.example.com 换成内网网关地址。回编、对齐、签名，装到巡检平板上。打开就报证书错误，因为内网是自建 CA，设备不信任；找运维下发 CA，装到设备的受信任凭据里，再打开。这次能进登录页了，但提交巡检任务超时，查下来是内网端口没开全，网关端口通了，上传端口没通。等网络组开端口，再验一轮。整个过程最大的成本不是改包，是“等”和“猜”。

现在怎么做。同样拖入 APK，需求里写清：只改 assets/app_config.json 的 gateway.base 和 strings.xml 的 upload_host 两处；旧值是外网域名，新值是内网域名加 8443 端口，路径 /ops 保留；边界写明不动内网 CA 信任逻辑、不动证书校验、不动任务业务代码；验收写明登录、任务下发、图片上传、离线缓存、证书链五项。附件给三样：内网端口对照表（网关、上传、文件服务三个端口）、运维提供的 CA 说明截图、旧配置文件。AI 改完，工具自动打包并装到平板，验证时先确认平板能解析内网域名，再确认三个端口都通，最后走一遍完整任务流。

改完怎么验证。先在平板的浏览器里打开内网网关，确认能出登录页，这一步排除 DNS 和端口问题；再打开应用登录，确认走的是内网域名；然后下发一条巡检任务，确认任务能到设备、能回传；接着上传一张现场照片，确认上传端口通、大文件不超时；最后把平板切到飞行模式再恢复，确认离线缓存和重新同步正常。证书这块单独确认：不是“能打开就行”，而是确认证书链完整、CA 已被设备信任、没有人在客户端里关掉校验。

对比项	记账 App（测试到正式）	巡检工具（外网到内网）
地址层级	字符串资源加 assets 配置，两处	assets 配置加上传地址常量，两处
最大风险	签名指纹变化导致后台 401	自建 CA 不受信、端口未开全
关键附件	接口对照表、白名单截图	端口对照表、CA 说明
验证重点	登录、分页、上传、token 刷新	DNS、端口、证书链、大文件上传
回退方式	装回原包，旧环境保留观察期	装回内网旧包，旧网关继续保持可达

九、常见失败排查：先看现象，再看层，最后看签名

排查最忌讳“一上来就重新打包”。重新打包会覆盖现场，让你失去判断依据。正确顺序是：先看现象属于哪一类，再看请求 URL 和返回码，再看证书和签名，最后看后台配置与缓存。下面这张表按现象归类，覆盖了环境切换中最常见的十二种失败。

现象	常见根因	处理办法
启动即闪退，日志提示 URL 非法	地址含全角标点、空格、缺协议	逐字比对，重新下发一条只含单行 URL 的需求
登录一直转圈，最终 401	新域名未加白名单，或签名指纹变了	后台补域名与证书指纹，不要反复重试账号
接口 404 或 301	少了路径、多了斜杠、网关规则未同步	对照接口文档核对 path，确认结尾斜杠
请求被明文流量策略拦截	新地址是 http，高版本系统默认禁止	改用 HTTPS，或由研发评估网络安全配置
SSLHandshakeException	证书 SAN 不含新域名、自建 CA 不受信	换证书或下发 CA，不要关闭校验
证书固定校验失败	应用预置了旧证书指纹	由研发更新 pin，或改走远端下发
首屏很慢、频繁超时	内网 DNS 解析慢、跨网段、端口未开	先测 DNS 与端口，再评估超时参数
部分页面正常，部分报错	只改了主接口，图片、上传、长连接没改	回到定位清单，逐个域名核对
改了但像没生效	多语言资源覆盖、远端配置覆盖、本地缓存	查 values 全目录、查配置中心、清缓存再试
回编失败	资源引用错误、图片格式异常、工程不完整	看 apktool.log 的最后一段错误上下文
安装失败，提示版本不兼容	签名与已安装版本不一致	卸载旧版或用原证书签名，卸载前先备份数据
verify 不通过	密钥格式错误、别名不对、口令错误	看 pack.log 的签名阶段，核对证书链
推送、支付、地图失效	误改了第三方域名或 key	按台账还原第三方配置，只保留自家改动

这张表的使用方法是“先归类再动手”。闪退类问题看 URL 解析；能启动但登录失败看返回码；返回码正常但页面空看数据；页面部分正常看域名覆盖；装不上看签名；装上了但某个功能坏看第三方 SDK。每类问题的排查入口不同，混在一起看只会浪费时间。

实际排查时，建议固定按下面这个顺序走，每一步只回答一个问题，答不出来就停在原地，不要跳步：

1. 异常类型是什么。闪退、401、404、握手失败、超时，这五类的排查入口完全不同，先归类再动手。
2. 请求打到了哪个地址。从 logcat 或抓包里拿到完整的 host 与 path，确认不是旧域名、不是双斜杠、不是少路径。
3. 证书是否通过。看证书链、SAN、有效期、是否被设备信任，确认没有 pinning 冲突。
4. 签名是否被后台接受。把 verify 打印的证书指纹和后台白名单逐位比对，确认不是身份问题。
5. 后台配置是否同步。域名白名单、网关路由、跨域设置、证书绑定，任何一项没同步都会表现为“客户端有问题”。
6. 缓存是否在捣乱。远端配置缓存、WebView 缓存、DNS 缓存，清掉再复测一次，确认现象可复现。

再强调一次日志的分工：apktool.log 管反编译和回编，pack.log 管对齐、签名、verify，error.log 管未处理异常，dock.log 管窗口吸附和布局。环境切换主要看前两个，外加设备的 logcat。把 logcat 的包名过滤打开，只看自家进程，异常堆栈的第一行通常就写着原因，比如 UnknownHostException、SSLHandshakeException、IllegalArgumentException。看不懂栈没关系，把第一行和请求 URL 贴到需求里，下一轮就能改对。

十、把流程固化成团队习惯

单次切换做对不难，难的是每次都对。建议把这篇教程压缩成一页纸，放在团队文档里，包含五样东西：一份需求模板、一张变更台账、一套附件命名规则、一张验证清单、一次回退演练记录。需求模板就是前面那段四要素，台账是那张十列的表，附件命名统一成“环境_用途_日期”，验证清单固定十项，回退演练每季度做一次，确保原包真的能装回去、旧环境真的还在。

还有三个习惯值得坚持。第一，先定位再改，永远不要在没搞清楚层级的情况下批量替换。第二，一次只改变一个变量，地址就是地址，超时就是超时，改名的另开一轮。第三，任何一次正式环境切换都保留观察期，旧环境不着急关，新包先小范围装，确认无异常再扩大。做到这三点，换服务器地址就会从“碰运气”变成“走流程”。

回退方案再补充一个细节：回退不是“把旧包装回去”这么简单。旧包装回去之后，本地数据库可能已经被新版本升级过，字段不兼容会导致启动崩溃；旧包连的旧环境如果已经下线，装回去也登录不了。所以回退演练要覆盖三件事：旧包能覆盖安装或卸载重装、旧环境接口仍可访问、本地数据能兼容或被清理。演练时用测试设备，不要用真实用户的设备。

到这里，整套流程就闭环了：先确认地址在哪一层，再备份，再把需求写成四要素，再用附件把对照关系说清，再让 AI 执行，再看懂打包四步和 verify，再按四个维度验证，最后用排查表收尾。每一步都不复杂，难的是不跳过任何一步。记住那句口号：只需说话，就能让应用变成你想要的样子。但说话之前，先把旧值、新值、边界和验收想清楚，这句话才会真的成立。

用户评价

“以前换环境最怕漏掉 assets 里那份配置，现在按四要素写清楚，两处一起改，history 里还能翻回原话，不用每次重新解释。”
—— 陈默，独立开发者

“内网切换最难的是证书和端口。附件里把 CA 说明、端口表给全，AI 改完直接装平板，少走了两轮弯路。”
—— 林工，企业内网运维

“签名指纹那段说到点子上了。我们后台白名单加上新证书，401 立刻消失，之前一直以为是账号问题。”
—— 阿凯，小团队后端

“我不写代码，但按模板把旧值、新值、边界、验收写清楚，也能把需求提明白，验证时对着清单打勾就行。”
—— 苏苏，产品经理

“回退方案那段很实用。先留原包、再确认旧环境在线，交付时心里有底，客户问起来也答得上。”
—— 老周，外包交付