超时、重试、BaseURL、请求头：网络配置到底写在哪一层（自有应用篇）

先把主角介绍清楚。安卓修改大师智改工坊是一款 Windows 桌面工具：拖入安装包，用中文写一句需求，AI 去改 smali 与资源，改完自动回编、对齐、签名、校验，最后一键装到手机或模拟器上看效果。它的介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

网络层改造是实际工作里最常出现的一类需求：内测要换地址、联调要加超时、抓问题要统一 UA、压测要把重试关掉。这些动作本身都不复杂，复杂的是找到该改的那一行——同一份配置在包里往往不止一份，"改了一处没生效"几乎是每个做这类改动的人都会撞上的墙。

这篇分四块讲：网络配置常落在哪几层（为什么它会有四个家）、"改了一处没生效"的三类根因（多份拷贝 / 缓存 / 签名与安装路径）、从关键字到落点的定位清单（可以直接照着走），以及怎么把需求写成 AI 一次就能做对的样子（原话 + 附件说明 + 固定环境说明的三层结构）。

一、先把边界划清：这类改动只对自家应用做

在任何技巧之前，先把话说透。网络配置属于一个应用自己的实现细节，改它的前提是你有权改这份代码、这个包：自有版权、团队内部自研、或者已经拿到书面授权的定制项目。这是本文全部方法的适用边界。

现实里最容易被误用的一步，是把它用到别人的商业应用上：改接口地址、改 UA、改超时，这些动作一旦脱离了自有场景，就很容易滑向流量劫持、伪造客户端、绕过他人保护这类行为。这不是工具的设计目标，也不在本文的讨论范围。所以把这句话明确写在这里：请勿用于破解他人付费应用、绕过安全机制或未获授权的分发。

判断能不能动手，其实只需要回答三个问题：这个包是不是我们自己的（或书面授权的）？这次改动是不是为了内测、联调、自有业务迭代？验证是不是在自有设备和自有服务端之间进行？三个都是"是"，再往下看；只要有一个不是，就停在这里。

工具侧也有一条与之匹配的设计，值得提前知道：签名用的是工作目录根目录下的 testkey.pk8 与 testkey.x509.pem，这两个文件是可以替换的。对自有应用来说这一点很关键——换成自家应用一直在用的那套密钥，新包才能和线上包同签名，覆盖安装才顺，后面的"根因三"会展开讲这件事。

二、网络配置的四个落点：为什么它天生有四个家

一个 App 的网络行为，归根到底由几组参数决定：基地址（域名 / BaseURL）、超时（连接、读、写）、重试次数与退避策略、请求头（UA、鉴权、渠道标识），再加上证书与代理相关配置。这些参数在工程里很少只住一个地方，最常见的四个落点是：常量类、资源字符串、拦截器、assets 里的配置文件。

为什么会有四个家？因为每一层解决的是不同的问题：常量类服务于"编译期就确定"；资源字符串服务于"打包时能被替换"；拦截器服务于"所有请求统一处理"；assets 文件服务于"运行期可换"。当项目跨了几个人、多活了几轮环境，这四层就会同时存在——这是结构性的，不是谁粗心。

其中最容易在排查时被忽略的是 assets 这一层，原因有两个。第一，它不在代码里，搜索"域名"时如果只看代码目录就会直接跳过去；第二，它的存在感往往被"程序会把它读出来用"这件事掩盖住了——你知道配置是从文件读的，却不一定知道读的是包里那份，还是被搬到别处的那份。所以判断顺序建议是：先看代码与资源这两条"明显"的线，再专门花两分钟扫一遍 assets，最后再回头确认读取逻辑。这三步做完，"有几份"这件事基本就清楚了。

落点	在包里长什么样	改动方式	最容易踩的点
常量类 / 单例	smali 里的字符串常量	改字符串值	同一域名有带斜杠、带端口等多种写法
资源字符串	res/values/strings.xml 条目	改 XML 后回编	多语言目录各有一份，只改了默认的
拦截器 / 中间件	加头、超时、重试的代码逻辑	改逻辑或改其中的常量	同一套逻辑被复制到多个客户端
assets 配置	json / properties / xml 文件	直接替换文件	被拷到私有目录成了"影子配置"

这里有一个反直觉的结论，值得单独记一笔：改哪一层，取决于"这个值的最后一道防线在哪"。 如果代码写的是"先读 assets，读不到才用常量"，那你就得改 assets；如果拦截器里又硬写了一遍 UA，那配置文件改得再对也没用。第四章的定位清单，本质就是围绕"找最后一道防线"来组织的。

三、为什么"改了一处没生效"：三类根因

这是网络层改造里最花时间的一环。而且大多数时候，问题不在"AI 改错了"，而在于包里本来就有第二份、第三份。把根因归成三类，排查就有了顺序：先查多份拷贝，再查缓存，最后查装的是不是新包。

根因一：多份拷贝 —— 同一个值在多个位置各有一份

先看环境维度：内测、预发、生产几套地址，常常同时写在几处——常量类里一套，assets 里一套，有时候构建脚本还会往 strings.xml 里塞一套。再看模块维度：多个业务模块各自封装了一套请求客户端，各自写了一遍超时与 UA。还有写法维度：同一个域名可能是 http 与 https 两种、带不带 www 两种、带不带路径前缀两种，你改了一种，另一种照旧命中。

举一个真实感很强的现象：把域名换掉之后，登录页通了，但"埋点上报"仍然打向旧地址。原因往往不是漏改，而是埋点模块自己有一份独立的客户端配置。这类问题的可怕之处在于它不会报错——从界面上看一切正常，只有服务端日志才能看出来有请求去了旧地址。

要"数清楚有几份"，最省力的办法是按包里的三条线各扫一遍：代码线（反编译出来的 smali 目录，关键字直接搜字符串常量）、资源线（res/values 下的字符串与数组资源，含多语言目录）、资产线（assets 下的配置文件）。三条线都过一遍，心里就有了一张"这份值一共出现在哪里"的地图；之后再谈改哪一处，才不会陷入"改一处、装一次、发现还有一处"的循环。

根因二：缓存与"看起来生效了"

第二类根因更隐蔽。其一，静态初始化只跑一次：不少客户端在应用启动时读一次配置，之后不再读，改包后不重启进程是看不到变化的。其二，assets 里的配置会被"搬走"——很多应用在首次启动时把 assets 下的配置文件拷到应用私有目录或写进本地存储，之后读的都是那份副本；你换了 assets 里的文件，副本还是旧的。

其三，远端下发的配置会覆盖本地默认值：不少应用有"配置开关"能力，服务端返回的地址与开关优先级高于包内的默认值。这种情况下，只改包不改服务端，就是真的不会生效——这属于设计使然，不是改漏了。其四，还有一层是容器与框架的缓存：接口响应、图片的磁盘缓存会让"内容"看起来没变，但请求其实已经打到新地址了。

所以验证时要分清两件事："请求打到哪里"和"页面显示什么"。 前者看服务端访问日志最准（这是自有服务端的好处）；后者可能是缓存，不能作为唯一判据。

根因三：签名与安装路径 —— "改了，但根本没装上"

第三类最容易被误判成"改包没生效"。事实是：重新签名之后，新包的签名与原包不一致（工具默认用的是自带的测试密钥，和任何线上密钥都不同），系统会拒绝覆盖安装。安装失败时，手机桌面上那个应用还是旧的那一个——于是你看到的现象就是"地址改了，但请求还是打旧的"。

处理方式其实就两句话：要么先卸载旧版再装（内测设备上通常可以）；要么把工具的签名密钥替换成自家应用一直在用的那一套——工作目录根目录下的 testkey.pk8 与 testkey.x509.pem 就是为这件事留的口子。密钥可替换，是"自有应用改造"这条路线能走得顺的前提。

还有更深一层的现象要说明：如果应用自身在启动时做了完整性或签名自检，那么重签之后的包可能启动即退出、或者关键功能被禁用。这类自检是应用自己的代码，处理方式只能是在自有代码与自有签名的范围内，由开发者自己调整自检所比对的配置——它属于自有工程的构建流程问题。本文限定"自有应用、自有密钥"，并且不涉及任何绕过安全机制的做法，这一点在本章格外要说清。

基于这些根因，"改完没生效"的排查顺序应该反过来：第一步不是回去改代码，而是先确认手机上跑的是不是刚打出来的那个包。 工具在这条链路上安排了两个抓手：打包最后一步会做一次签名校验并打印证书信息（能直接看到"确实签上了"），装机之后还会用系统命令复核一次前台应用是不是它——避免"装上了但没起来，却以为改失败"的误判。

四、从关键字到落点：一份可以照着走的定位清单

把上面两章合成一套动作，就是下面这份清单。它的价值在顺序：先确认"有几份"，再决定"改几份"。跳过第一步直接改，最常见的结局是改一处、装一次、发现还有一处。

搜什么关键字	首选落点	判断要点
https:// 、已知域名	常量类 + assets	注意同一地址的多种写法，改全
timeout / connectTimeout	拦截器 / 封装类	先确认单位，再确认是不是多个客户端
retry / maxRetries	拦截器 / 封装类	重试会放大重复提交风险，压测前务必确认
User-Agent / X- / token	多个模块各写一遍	按"头名"搜一遍，再按"写入动作"搜一遍
server_url / api_host	资源字符串 / 配置文件	多语言资源目录可能各有一份
渠道 / 环境标识	清单文件里的 meta-data	常与客户端配置成对出现，别只改一处

这张表配合前面的六步动作，能覆盖大部分自有应用的网络层定位。剩下的少数情况（配置被加密、地址被运行时拼装）需要开发者自己对照源码来确认——工具能做的是把"找出所有出现位置"这件事做得比人眼快、比人眼全。

还有一个反向的用法值得一试：在需求里要求"改完告诉我改了哪几个文件"。 这不是客套话，而是给"改全了没有"留一份可核对的凭据。拿到文件清单之后，你可以回到项目目录里逐个看一遍；如果发现同一份域名在清单里只出现了一次，而你之前手工排查时记得还有第二处，那就说明该把范围写得更明确一些，再来一轮。把这种"清单核对"养成习惯之后，你会发现自己在写需求时就已经开始主动交代范围了。

五、把需求写清楚：三层结构与环境说明

定位清楚了，接下来是"怎么把这件事说给 AI 听"。这里有一个很多人不知道的机制：你写在输入框里的需求，并不是原样发出去的，它在发出去之前会被拼成三段——你写的原话 + 附件说明 + 固定的环境说明。理解这三层各自的作用，是从"改了三轮"到"一次做对"的关键。

为什么要这么分层？两个理由。其一，历史要干净：如果每次记录里都塞进几百字的环境说明，翻历史就变成翻噪音。其二，顺序要正确：附件说明属于"这次改什么"，所以放在需求之后；环境说明是操作约定，必须压在最后——它管的是"怎么干活"，不是"干什么活"。文件校验同理：带着一条坏路径或一句空说明发给 AI，只会让它瞎猜。

环境说明里"不需要自动打包"这半句也值得解释一下：打包由主窗口按固定流程做（回编、对齐、签名、校验四步，产物统一落在项目的 build 目录里），如果让 AI 自己去打包，产物就不在这条受控链路上了——你既看不到 pack.log，也可能拿到一个没对齐、没校验的包。把职责划清楚，是这套流程能稳定复现的前提：AI 负责改，主窗口负责打包与装机，两头各管一段。

等待机制顺带说清：标志文件叫 ai_done.flag，主窗口 2 秒轮询一次，读到就删掉然后自动弹打包窗口；开始等待前会先清一次同名残留，避免把上一轮的旧文件误判成这一轮改完。等待上限是 1 小时，超时就不再挂着"等待中"。之所以用"文件"当信号，是因为右侧的 AI 是个聊天窗口，没法直接回调主窗口——一写一读的约定最简单，AI 也最容易照做。

怎么写需求：把"目标值、范围、验收"三件事写进去

先看一个反例，一行字："把网络超时改长一点。" 这句话里有三个洞：改哪一层？"长一点"是多长？重试要不要跟着改？AI 只能猜，猜错一次就要重来一轮。

再看正例："把应用里所有网络请求的连接超时与读超时统一改成 30 秒，重试次数改成 1 次；如果代码里的超时常量有多处副本，请一并统一，不要只改其中一处；不要改动任何接口地址与请求参数。" 这段里，目标值（30 秒、1 次）、范围（所有请求、多份副本一并改、不要动地址）、验收（打开登录页能正常登录内测环境）三件事都齐了。

如果一时不知道怎么组织语言，可以直接用话术库：它按 6 大分类（界面美化 / 弹窗引流 / 去除限制 / 常规修改 / 混淆去毒 / 插件添加）收了 3000 条成型指令，每条都把"要做什么 / 细节要求 / 参数参考 / 范围 / 验收"写全。点「选择」直接填进输入框，再按自己的域名和数字改一遍即可；内容来自程序目录下的 Resources\话术库.xml，这个文件可以手工改，改完点一下刷新就重新读。

发送之后，主窗口这一侧的流程是自动的：AI 改完留下标志文件 → 主窗口读到 → 弹打包窗口 → 回编（apktool b）、对齐（zipalign -f -p 4）、签名（apksigner + testkey）、校验（apksigner verify）四步依次跑，产物落在项目目录的 build 子目录里（未签名、已对齐、已签名三个中间件都在），全过程写进项目目录下的 pack.log。

最后一步的校验不是多余的：前三步只看退出码，而"到底签没签上"要 verify 说了算——万一密钥格式不对，只有这一步会明确报出来。校验会打印证书信息，这一行就是"这个包确实签好了"的直接证据。之后如果勾选打包后自动运行，程序会用 adb 找到手机或模拟器，装上并拉起应用（拉起用的是 am start 而不是 monkey：新版系统镜像里已经没有 monkey，而且它失败时退出码还是 0，容易造成"以为成功了"的误判），装完还会用系统命令复核一次前台应用是不是它。

六、两个自家应用的改包实例

下面两个例子都来自我们自己和同事的日常工作，包是自家的、服务端也是自家的，重点看"以前怎么做、现在一句话怎么做、改完怎么验证"这三步。

实例一：给内部「考勤打卡」应用切换内测环境地址。

以前的做法是一条来回折腾的流水线：先用反编译工具打开自家包，搜域名，在常量类里找到那一行，改掉、回编、签名、装机。结果登录页还是打生产接口——因为包里还有第二份地址写在 assets 的配置文件里。把第二份也改了，发现又多出一次：多语言目录里的字符串资源还留着一份旧的。前前后后改了三次，每次都要重新反编译、回编、签名、装机，一次十几分钟，而且每次都在"到底还有没有第四处"的疑虑里收尾。

现在一句话：把自家的安装包拖进安卓修改大师智改工坊建立项目，在需求框里写"把应用里所有出现 api.xxx.internal 的地方统一替换成 api.test.xxx.internal，包括代码常量、资源字符串与 assets 下的配置；如果有多处副本请一并处理，不要只改其中一处，也不要改动其它接口地址"。再把服务端同学给的《内测环境说明.txt》作为附件加上，用途写清"内测环境的域名与端口，请按它替换旧地址"——这一栏至少 10 个字，写清楚就不会有歧义。

改完怎么验证？分三步：第一，打包四步跑完后看校验输出里那行证书信息，确认签名真的签上了；第二，勾选打包后自动运行，程序把包装到模拟器上并拉起，手机那边走投屏、模拟器这边把窗口提到最前，你直接看登录页；第三，也是最有说服力的一步——打开自家内测服务端的访问日志，在应用里点一次登录，看是不是有新请求打进来。前两步确认"包是对的、应用起来了"，第三步确认"请求真的换了地方"。三条都对上，这次改动才算闭环。

实例二：给内部「巡检打卡」工具统一请求头与超时策略。

这个工具是给巡检同事用的内部应用，问题出在"请求头各写各的"：几个业务模块各自封装了请求客户端，有的带内部标识头、有的没带，导致某个页面偶尔报鉴权失败；超时也是各写各的，巡检现场网络差的时候，有的页面要等很久才报错。

以前要改这类问题，得先全量搜 addHeader、User-Agent 这些关键字，把每一处都找出来，再挨个改、挨个回编签名装机——最麻烦的是"改全了没有"只能靠人眼盯。现在同样是一句话："把所有网络请求的 User-Agent 统一改成 XunJian/2.0，并统一加一个 X-Client 请求头，值为 internal-debug；连接与读超时统一改成 20 秒，重试次数改成 1 次，避免现场重复提交；不要改动任何接口路径与参数。" 附件里放一份内部接口约定文档的片段，说明写"这是内部约定的请求头与超时标准，请按它统一"。

验证方式也顺理成章：自家服务端记录到的 UA 是不是统一成了一条；把之前会报鉴权失败的那个页面点一遍，看是否还失败；再把巡检提交动作做一次，确认没有产生重复记录（重试次数改成 1 的意义就在这里）。三件事都在自有服务端与自有设备上完成，不涉及任何第三方的系统。

两个实例放在一起看，能看出这类改动的共同点：难的不是"改"，而是"改全"和"确认"。 前者靠定位清单和一句写清楚的需求，后者靠打包校验与可复核的运行链路——把这两件事变成流程里的固定动作，"改了一处没生效"就会从常态变成偶发。

七、用户评价：他们踩过的坑，大多能对上这三类根因

八、结语：四个落点、三类根因、三层需求

把这篇收成一句话：网络层的改动之所以"看起来简单、做起来反复"，是因为它同时受四个落点（常量类 / 资源字符串 / 拦截器 / assets）、三类根因（多份拷贝 / 缓存 / 签名与安装路径）和三层需求结构（原话 + 附件说明 + 环境说明）三件事影响。想清楚这三件，再从"关键字 → 落点 → 最后一道防线"的顺序下手，绝大多数问题都能一次收敛。

如果只带走一个习惯，希望是这个：下次写网络层需求时，先把"改哪一层、改成什么、怎么算改完"三句话在心里过一遍，再动手写。这三句话分别对应定位、参数与验证——它们覆盖了这类改动里绝大部分的返工来源。写得慢一点，改得快很多。

还有一条底线值得重复：这类改动只对自有版权或已获授权的应用做。自己的包、自己的服务端、自己的设备，改起来才理直气壮；别人的商业应用、付费内容、他人设下的安全机制，一概不在讨论范围内。工具把签名密钥做成可替换的，也正是为了让"自有应用"这条路走得更顺，而不是反过来的用途。

回到那句一直在强调的话：打开安卓修改大师智改工坊，拖入自家的包，把"改哪一层、改成什么、怎么算改完"写清楚——只需说话，就能让应用变成你想要的样子。改完自动回编、对齐、签名、校验，一键装到设备上看效果，剩下的时间留给真正需要判断的事情。

产品介绍页与下载入口：https://www.apkeditor.cn/ai-version.aspx（官网 www.apkeditor.cn）。