改包后的二维码与邀请链接：包名、签名和渠道参数对齐

先把一个常见误会说清楚：二维码本身不包含应用，也不认识包名。它只是一段文本的图形化写法，扫出来的可能是网址、自定义协议，也可能只是一串编号。真正决定“扫完发生什么”的，是这段文本指向哪里，以及手机上装着的应用有没有能力接住它。所以改包之后发现二维码失效，第一反应不应该是重新做一张图，而是把二维码里的那段文本找出来，和新的包名、新的签名、新的渠道参数逐项对照。

这件事在只改图标、只改文案的时候不容易暴露。因为包名没变，签名没变，链接还是原来那条，扫码当然正常。一旦改动触及应用名称、包名、签名或者分享配置，问题就会集中出现。尤其是做新品牌线、内测版、渠道包、活动包的团队，往往一次改包要同时面对好几套链接，哪一套没跟上，哪一套就会在活动当天出问题。

本文使用的工具是智能修改电脑版。它在导入 APK 时就会解析出应用名、包名、版本号和启动页，项目列表与详情页都能直接看到这些信息；打包时会依次完成回编、对齐、签名和校验，并把签名指纹打印在打包结果里。我们要做的，是拿这些“看得见的事实”去校正二维码、邀请链接和渠道参数，而不是凭记忆猜。

合规边界先放在前面：本文只讨论自有版权或已经获得授权的应用，例如公司自己的产品、内部工具、给客户做的定制应用。请勿把改包能力用于破解他人付费应用、去除授权校验或绕过安全机制。二维码和邀请链接的调整，也应该在授权范围内进行，涉及品牌素材、用户数据、渠道结算时，最好留下书面确认。

二维码是“门牌”，包名是“房间号”，签名是“钥匙”，渠道参数是“从哪条路进来的记录”。门牌换了，房间号没换，人就会走错门。

图 1：扫码之后发生什么，由链接内容和应用身份共同决定，二维码图片只是载体。

一、先分清三种“对不上”：症状不同，修法也不同

改包后的链接问题，表面上都叫“扫不开”，实际原因差别很大。把症状分清楚，能少走很多弯路。最常见的三种是：链接指向了旧包名、安装时签名冲突、渠道参数在中途丢失。它们分别发生在不同的环节，核对的方法也不一样。

第一种，链接指向旧包名。多见于换品牌、换包名、做新包的情况。二维码里的应用市场地址还是 id=com.old.brand，手机上装的是 com.new.brand，系统当然找不到对应应用。自定义协议也一样：链接写的是 oldbrand://invite，新包里只注册了 newbrand://invite，点开只会停在浏览器或提示“无法打开”。

第二种，签名冲突。包名没变，但这次用了另一套密钥签名。系统会把它当成“同名但不同来源”的应用，覆盖安装直接失败，常见的提示是“应用未安装”“安装包冲突”或者“签名不一致”。更隐蔽的是分享、登录、推送这类依赖开放平台登记的通道：包名和签名指纹对不上，功能不会在安装时报错，而是在用户点分享的那一刻才失败。

第三种，渠道参数丢失。二维码里明明带着 channel=poster_a，用户扫码后落到下载页，下载页再跳应用市场，参数在两次跳转中被丢掉了。应用装上了，渠道统计却是空的。这个问题最容易被误判成“统计系统坏了”，其实是链接链路太长，中间某一跳没有把参数带过去。

扫码后的表现	最可能的原因	先查哪里
浏览器打开了下载页，应用没被唤起	没有注册对应协议，或 App Links 未通过验证	清单里的 intent-filter、assetlinks.json
提示“应用未安装”	链接里的包名还是旧的	二维码文本、应用市场地址、项目页包名
打开了旧版应用	旧包仍注册同一协议，且链接没有唯一指向	两台设备上的应用信息、协议 host
覆盖安装失败，提示签名不一致	同包名换了签名	apksigner verify 输出的证书指纹
能装能开，分享按钮报错	开放平台登记的包名或签名没更新	分享通道后台、签名指纹、包名
安装量有了，渠道统计为空	参数在跳转中被丢弃，或渠道包没打进去	最终落地页 URL、渠道包配置

这张表可以先帮你定位大致方向，但不要停在“大概是这个原因”。每一条都要落到一个能打开、能对照的文件或页面上：包名在项目详情页，签名指纹在打包结果和 verify 输出里，链接内容在二维码的原始文本里，渠道参数在最终落地页的地址栏里。能看到这四样东西，问题就不再靠猜。

还有一类情况不属于以上三种：二维码图片本身印得太小、对比度太低、被logo遮住太多，导致扫不出来。这类问题在活动物料上很常见，但和改包无关。判断方法很简单：把同一张二维码放在屏幕上放大，用另一台手机扫，如果能扫开，说明内容没问题，问题在印刷尺寸或拍摄条件。本文后面会单独讲二维码的生成与验收，这里先记住“先验内容，再验图像”。

二、包名对齐：先读项目页，再决定要不要改

包名是 Android 应用的唯一身份。它写在清单的 package 属性里，也决定了应用在系统里的数据目录、权限归属和升级关系。两个应用可以叫同一个名字、用同一个图标，但只要包名不同，系统就把它们当成两个完全独立的应用；反过来，包名相同但签名不同，系统会拒绝覆盖安装。二维码、邀请链接、应用市场地址之所以会失效，本质上是因为它们记录的是旧身份，而手机里装的是新身份。

在智能修改电脑版里，包名不需要你去解压清单里找。把 APK 拖进主窗口，程序会用工作目录里的 aapt 解析图标、应用名、包名、版本号、最低与目标 SDK、启动页，然后弹出项目命名窗口。建好项目后，项目列表每一行都会显示应用名和包名，详情页顶部也会再显示一次。这个值就是后续所有链接应该对齐的“基准值”，先把它抄到你的核对表里。

接下来要做一个决策：这次改包，到底要不要改包名？很多问题从源头上就来自“没必要改却改了”。如果只是换图标、换应用名、换启动页、换内置链接，包名完全可以保持不动。包名不动，签名不动，老用户就能直接覆盖升级，二维码和应用市场地址也不用改。这是成本最低、风险最小的路线，应该优先考虑。

只有几种情况值得改包名：需要和现有应用同时安装、做独立的内测版或渠道版、新品牌线要和旧品牌彻底分开、旧包名已经被占用或不符合命名规范。改包名不是改一个字符串那么简单，它会影响清单、代码里的包路径、硬编码的组件名、第三方 SDK 的回调、分享链接、推送注册、支付回调，以及所有外部物料。改之前，先把影响面列出来，比改完再补要省事得多。

策略	适合场景	链接要做什么
包名不变	换图标、换名称、换页面、换接口地址	原有链接继续用，重点核对签名和参数
包名加后缀	内测版、演示版，与正式版共存	内测链接单独一套，正式链接不要混用
换全新包名	新品牌线、独立产品、旧包不再维护	市场地址、二维码、协议、回调全部换新
同包名多渠道	同一产品按投放来源区分统计	包名签名不变，只换渠道参数或渠道配置

决定改包名之后，需求要写得足够具体。不要只写“把包名改成新的”，而要写清旧包名、新包名、哪些链接需要同步、哪些第三方配置需要更新、是否保留旧包。智能修改电脑版的详情页支持把需求原文送进右侧 AI 工作区，附件可以一次挂多个文件，每个文件写清用途。你可以把链接清单、开放平台配置截图、旧包名对照表作为附件挂上去，让 AI 在改代码和资源时有明确的参照。

这里有一个很容易被忽略的细节：包名不仅出现在清单里，还可能出现在代码字符串、资源文件、分享回调、推送别名、支付 scheme、WebView 的 JavaScript 接口名里。只改清单，应用可能能装能开，但点到某个功能就崩。验收时不能只看桌面图标，要把分享、登录、邀请、支付、消息这些和外部打交道的入口都点一遍。项目页的“浏览项目文件”可以打开反编译工程，文本文件能直接查看和手工编辑，适合用来核对硬编码的包名和链接。

改完包名后，第一件事是重新安装，然后在系统“应用信息”里确认包名。第二件事是回到智能修改电脑版的项目列表，确认显示的新包名和安装到手机上的包名一致。第三件事才是去改二维码和邀请链接。顺序反过来，就容易出现“链接改好了，包名又变了一次”的返工。把包名当作一个版本化的输入，冻结之后再做外部物料。

如果想更直接地核对，可以连上 adb，列出设备上的包名，再打开系统应用信息看版本号。命令行的好处是不会被桌面图标的名字骗到：图标可以换、应用名可以换，包名不会因为换图标而变。把命令行看到的包名、项目页的包名、二维码里的包名三处并排，任何一个不一致都能立刻发现。对于同时装了正式版和内测版的平板，这一步尤其值得做，因为两个图标可能长得几乎一样。

先冻结包名和版本号，再生成链接和二维码。外部物料一旦印出去，改一次就是一次成本。

三、签名对齐：指纹一变，哪些东西会跟着失效

签名是 Android 用来回答“这个包是不是同一个发布者出的”的机制。它不负责加密内容，也不负责隐藏代码，它负责身份和完整性。系统在覆盖安装时会比对签名：同包名、同签名，才允许升级；同包名、不同签名，直接拒绝。很多改包教程只讲“签上名能装就行”，但在真实业务里，签名还是开放平台、深度链接、推送、支付、分享等一大堆外部能力的登记依据。

智能修改电脑版在打包时提供四选一的签名方式：默认签名、自己的 JKS 或 keystore、自己的证书加私钥（PEM 加 PK8）、随机签名。签名方案支持 v1、v2、v3、v4，默认是 v1 加 v2 加 v3。打包的最后一步会执行 apksigner verify --print-certs，把证书指纹打印出来。多做这一步的意义很直接：前面几步只能说明命令跑完了，verify 才能说明“到底签没签上、签的是哪张证书”。

如果是公司自己的应用，应该优先使用公司长期保管的 JKS 或 keystore，而不是每次都用默认签名或随机签名。默认签名适合内测和临时验证，不能覆盖原应用的官方签名，也不适合对外分发；随机签名每次打包都会生成一套新的密钥，装到同一台手机上会被系统当成不同的应用，渠道更新和覆盖安装都会出问题。把签名文件、别名、口令的保管责任人写进交付文档，比把文件放在某个人的桌面文件夹里可靠得多。

签名变化会影响哪些东西？下面这张表可以作为核对清单。它不是吓唬人，而是提醒你：改签名不是一个只影响安装的动作，它可能让一串已经配置好的外部能力同时失效。

依赖项	签名变化后的表现	怎么核对
覆盖安装	同包名无法升级，提示签名不一致	旧包与新包的证书指纹
App Links 验证	HTTPS 链接不再直接打开应用	assetlinks.json 里的包名与 SHA-256 指纹
微信 / QQ 分享	分享面板能弹，发送或回调失败	开放平台登记的包名与签名
登录与支付回调	授权页能打开，回到应用后没有结果	回调 scheme、包名、签名配置
推送与统计	设备注册失败或数据归不到同一应用	平台应用信息、包名、签名摘要
渠道更新	新包装不上，用户只能卸载重装	版本号、签名、包名三件事一起看

读懂指纹，比记住一串十六进制更有用。apksigner verify --print-certs 会打印证书的 DN、有效期和 SHA-256 摘要。SHA-256 摘要通常写成用冒号分隔的十六进制，长度固定。App Links 的 assetlinks.json 需要的是 SHA-256 证书指纹；有些开放平台后台展示的是 MD5，两者不能混填。平台要求什么格式，就以平台说明为准，不要拿一种格式去猜另一种。

核对签名时，建议同时记录三样东西：签名文件的 SHA-256 文件哈希、证书的 SHA-256 指纹、以及这次打包使用的签名方案。文件哈希用来确认“用的是不是同一个密钥文件”，证书指纹用来填平台配置，签名方案用来排查低版本系统安装失败。三样都记下来，下次换人接手时，不用再靠“应该就是那个文件”来猜。

签名方案的选择也要按目标设备来。v1 是较老的 JAR 签名，兼容老系统；v2 从 Android 7 开始提供整包校验；v3 从 Android 9 开始支持密钥轮换等能力。默认的 v1 加 v2 加 v3 能覆盖大多数手机，除非有明确的兼容性要求，不要随意只勾一种。只勾 v1 可能在较新的系统上触发警告，只勾 v3 又装不进老设备。签名方案不是越多越好，而是要和你的用户设备分布匹配。

如果这次改包必须换签名，升级路径要提前设计。最直接的办法是让老用户先卸载再安装，但这会丢本地数据。更稳妥的办法是申请签名轮换或迁移方案，或者在旧包里预置迁移逻辑，具体能不能做取决于应用本身和平台政策。无论走哪条路，都要在二维码和邀请链接的落地页上写清楚“旧版用户如何升级”，不要让用户自己猜。对于内部应用，可以发通知、约时间、集中处理；对于外部用户，提前公告比事后解释有效。

还有一个小技巧：在打包完成后，不要只看“打包成功”四个字，把 verify 输出的指纹复制到核对表里，再和 assetlinks.json、开放平台后台逐字比对。人眼比对长字符串容易看错，可以分段比，或者用文本工具查找。指纹对不上时，先确认是不是拿错了项目、拿错了签名文件、或者平台缓存还没刷新，再怀疑打包流程。

图 2：签名不是打包的收尾动作，而是外部能力登记的凭据。指纹要能被复查。

四、渠道参数对齐：邀请码、渠道号和活动参数不是一回事

二维码和邀请链接里最常见的参数有三类：邀请码、渠道号、活动参数。它们看起来都是“一串字母数字”，作用却完全不同。邀请码回答“是谁邀请的”，通常和用户账号绑定，需要服务端校验、可能有有效期和使用次数；渠道号回答“用户从哪个入口来的”，用于投放结算和效果分析；活动参数回答“这次活动是哪一场”，用于区分素材、时间和落地页。把三者混成一个字段，后面做统计和结算时一定会打架。

设计链接时，先确定参数放在哪里。常见有两种做法：一种是把参数放在 URL 查询串里，由落地页或应用读取；另一种是把渠道配置打进 APK 里，做成不同的渠道包。两种做法各有适用场景，可以组合使用，但不要让同一个含义同时存在两个来源。否则用户从 A 渠道扫码，装的是 B 渠道包，统计系统到底信哪个，就说不清了。

做法	优点	限制
URL 参数	一个包走所有渠道，改参数不用重新打包	依赖跳转链路保留参数，落地页要能读
渠道包	参数跟包走，不依赖网络和跳转	每个渠道都要打包、签名、分发，管理成本高
两者组合	既能在物料层区分，又能在包内兜底	必须约定优先级，避免统计重复或冲突

如果包名没有变、签名没有变，只是给不同渠道发不同的二维码，那么最省事的做法是让二维码指向同一个 HTTPS 落地页，用不同的查询参数区分渠道。落地页负责判断用户有没有装应用：装了就用 App Links 或自定义协议唤起，没装就展示下载入口。这样一张海报一个参数，不需要为每个渠道重新打包，也不会因为渠道包版本不一致造成用户困惑。

如果业务要求参数必须跟包走，例如内网环境无法访问落地页、或者渠道方要求独立安装包，那就做渠道包。智能修改电脑版的话术库里有“渠道统计”这一类指令，可以在需求里明确写“只改渠道配置，不改包名、不改签名、不改版本号”。打包时使用同一套签名，产物按渠道命名归档。注意：同包名、同签名的渠道包不能在同一台手机上共存，用户装了一个渠道包，再装另一个渠道包，系统会按覆盖安装处理。如果需要共存，只能使用不同包名，那是另一种产品设计。

邀请链接的设计还要考虑“接收方没有装应用”的情况。只用自定义协议是不够的：没装应用时，链接点开通常没有任何反应，用户会以为链接坏了。更稳妥的做法是 HTTPS 链接加落地页，页面里同时提供“打开应用”和“下载应用”两个入口。如果使用 App Links，HTTPS 链接在验证通过后会直接打开应用；没有通过验证或没装应用时，仍然可以停留在网页上，给用户一个明确的下一步。

参数命名要稳定。渠道字段叫 channel 就一直叫 channel，不要这批物料叫 channel、下批叫 src、再下批叫 from。邀请码叫 invite，就不要和推广员 ID、活动 ID 混用。参数值尽量使用短横线或下划线，避免中文、空格和特殊符号；如果必须使用，先做 URL 编码。二维码里放的是最终 URL，不是“看起来像 URL”的文本，编码错误会让整条链接失效。

渠道参数的验收，不能只看“链接能打开”。要看到最终落地页的地址栏里参数还在，页面读取到的值和二维码里写的一致；如果应用会读取参数，还要在应用内的活动页或调试信息里确认。对于渠道包，则要确认安装后的渠道配置是目标值，而不是上一个项目残留的值。智能修改电脑版的项目目录里保留了原始包、工程和打包日志，出现“渠道值不对”时，可以回到项目核对需求原文和产物，而不是重新猜一遍。

邀请码记录“谁带来的”，渠道号记录“从哪里来的”，活动参数记录“哪一场”。三者分开，统计才说得清。

五、二维码怎么生成、怎么验收：别在最后一步省事

二维码的生成应该在包名、签名、链接三者都冻结之后进行。顺序是：确定最终包名，确认签名指纹，确定落地页和参数，生成二维码，再做印刷或投放。任何一步提前，都可能导致二维码返工。尤其是新品牌线，包名往往在最后一刻还会调整，这时候先印二维码，等于把风险印在纸上。

二维码内容优先选择 HTTPS 链接，不要直接放 APK 文件地址，也不要把自定义协议作为唯一内容。HTTPS 链接的好处是通用：Android 能打开，iOS 能打开，浏览器能打开，微信里也能打开；自定义协议只有在装了对应应用时才有效。如果业务必须用自定义协议，至少要在二维码旁边印一条短网址作为兜底，或者让二维码指向一个同时支持两种方式的落地页。

生成时注意几个工程细节。第一，纠错级别不要过低，物料暴露在户外、有磨损或反光时，中等以上纠错更稳。第二，二维码四周要留出足够的静区，不要把图形贴到边缘。第三，对比度要够，深色码点配浅色底，不要用低对比度的品牌色硬凑。第四，如果中间要放 logo，面积不要太大，放完必须用多台手机实扫。第五，印刷尺寸要按实际观看距离定，海报上的二维码不能按名片的大小去印。

二维码生成后，把原始文本单独存一份，和设计稿放在一起。文本里应该能看到完整的协议、域名、路径和参数。很多团队只存图片，不存文本，过了两个月要换域名或改参数，只能拿图片去识别，识别出来还不一定准。存文本还有一个好处：可以用文本对比工具检查新旧两版到底差在哪，是包名变了、域名变了，还是参数丢了。

链接越短，二维码越疏，扫起来越稳。如果原始链接很长，里面又带了一串参数，可以先过一层自己的短链服务，但短链服务必须保留参数，或者把参数写进短链的映射表。不要用第三方的免费短链做长期物料，服务下线、域名更换、跳转规则变化，都会让已经印出去的二维码失效。短链是入口，不是一次性工具，选的时候要按长期资产的标准来选。

验收要覆盖三种设备状态：装了旧版应用的手机、装了新版的手机、什么都没装的干净手机。三种状态下的预期结果不同：旧版手机应该被引导升级或打开新版，新版手机应该直接打开目标页面，干净手机应该看到下载页或应用市场。只测自己这台“什么都装好了”的手机，很容易漏掉最关键的新用户路径。

1. 用系统相机扫一次，确认能识别，不依赖某个特定扫码应用。
2. 用微信扫一次，确认微信内打开时不会被拦截或提示风险。
3. 在装了旧包的手机上扫，确认是升级提示，不是“应用未安装”。
4. 在干净手机上扫，确认下载页能打开，下载按钮指向正确的包。
5. 安装后从桌面图标启动一次，再从二维码扫一次，确认都能到达同一页面。
6. 把最终落地页地址复制出来，确认参数没有被跳转丢掉。

如果应用注册了 App Links，可以用 adb 做一次更直接的检查。连接手机后执行查看应用链接状态的命令，确认目标域名处于已验证状态；再用 am start 带上完整的 HTTPS 链接，观察系统拉起的是哪个应用。这个检查比“点开看看”更准确，因为它能看到系统实际解析到了哪个组件。智能修改电脑版在打包后会自动装到手机并拉起应用，adb 环境本来就是通的，顺手做这一步不麻烦。

最后，二维码的版本要和物料版本绑定。海报 A 版对应二维码 A，海报 B 版对应二维码 B，不要把同一个二维码文件复制到不同活动里再用。每换一次活动参数，就生成一个新文件，文件名里带日期和渠道。这样做看起来麻烦，但能避免“明明换了参数，扫出来还是上一场”的问题。

图 3：二维码验收至少覆盖旧版、新版、干净设备三种状态，不能只测自己这一台。

六、三个自家应用实例：以前怎么做，现在怎么做，改完怎么验证

下面三个例子都来自自有或已授权的应用。写出来不是为了展示“改得多快”，而是为了说明每一步的核对依据。你可以把它们当成模板，替换成自己的包名、签名和渠道参数。

实例一：自有品牌商城开新品牌线，包名从旧品牌换成新品牌

背景：公司有两个品牌，原来共用一个商城应用。新品牌要独立运营，要求能和老应用同时安装，图标、名称、启动页、首页 banner 都要换，邀请链接也要分开统计。这个场景必须改包名，因为同包名无法共存。

以前的做法：在开发环境里改 applicationId，改完发现代码里有硬编码的包名、分享回调、推送别名，逐个搜索替换；打包用命令行，签名用另一套 keystore；二维码由运营手工在小程序里生成，链接里的包名经常忘改。最严重的一次是海报已经印了三百张，扫码提示“应用未安装”，最后只能重新印。

现在的做法：把旧版 APK 导入智能修改电脑版，项目页确认旧包名；在需求里写清“包名从 com.oldbrand.mall 改为 com.newbrand.mall，应用名改为新品牌名，同步修改分享回调、推送别名和内置邀请链接”，把链接清单作为附件挂上，每个附件写清用途；签名选择公司的新品牌 keystore，v1 加 v2 加 v3；点“立刻修改”，AI 完成后自动弹打包窗口，回编、对齐、签名、verify 一路跑完。

改完怎么验证：第一，在项目列表确认新包名；第二，把新包装到一台已经装了旧应用的手机上，确认两个图标同时存在、可以分别启动；第三，打开系统应用信息，确认包名是新品牌；第四，扫新二维码，确认打开的是新应用而不是旧应用；第五，在微信里分享一次商品链接，确认分享面板和回调正常；第六，把 verify 输出的 SHA-256 指纹填进新域名的 assetlinks.json，再用 adb 检查 App Links 状态。六步都过，才把二维码交给印刷。

实例二：自有内部巡检工具做内测版，包名加 .beta 后缀

背景：巡检工具正式版已经在门店使用，新版本要加离线巡检和新的上报接口，需要和正式版同时装在一台平板上对比。正式版包名是 com.company.inspect，内测版用 com.company.inspect.beta。

以前的做法：开两个构建变体，改包名后缀、改应用名、改接口地址，分别打包、分别签名；内测群的二维码是手工拼的链接，偶尔会把正式版的下载地址发到内测群，测试同事装完发现没有新功能，又回来问。内测版和正式版共用一套签名，虽然能装，但分享和推送的配置经常串。

现在的做法：复制一份正式版 APK 的项目，在内测项目里用一句话说明“包名改为 com.company.inspect.beta，应用名改为巡检工具内测版，接口地址改为内网测试环境，渠道参数设为 beta”，签名选择内测专用 keystore；打包后在项目页确认包名、版本号和签名指纹；二维码单独生成，链接里带 channel=beta，不和外发物料混用。

改完怎么验证：在一台已经装了正式版的平板上安装内测版，确认两个应用并存；分别启动，确认内测版连的是测试接口；用内测二维码扫码，确认打开的是内测版；把正式版的二维码再扫一次，确认仍然打开正式版；在微信里分别分享两个应用的一个页面，确认回调没有串。最后把两个包的签名指纹并排记录，避免下次打包拿错密钥。

实例三：自有教学应用做三个渠道包，包名和签名都不变

背景：教学应用参加三场招生活动，分别投放在公众号、线下门店和合作机构。三个渠道需要分别统计安装量，但产品功能完全一样。这个场景不需要改包名，也不需要换签名，只需要区分渠道参数。

以前的做法：每个渠道打一个包，手工改渠道配置文件，三个包分别签名；因为签名相同、包名相同，用户先装 A 渠道再装 B 渠道，系统按覆盖安装处理，渠道值有时候还是旧的。二维码由不同的人生成，参数命名不统一，统计后台出现了“gzh”“wechat”“公众号”三个值。

现在的做法：只维护一个主包，包名、签名、版本号保持一致；用智能修改电脑版复制项目，分别生成三个渠道包，需求里只改渠道配置，不改其他内容；二维码统一指向同一个 HTTPS 落地页，只用 channel 参数区分，参数值固定为 gzh、store、partner；每个二维码文件按“日期加渠道”命名，原始文本和设计稿放在一起。

改完怎么验证：三个渠道包分别安装到三台干净手机，确认包名和签名一致、渠道值各不相同；扫三个二维码，确认落地页参数正确；从落地页下载安装，确认安装后的渠道值没有被覆盖；在统计后台按 channel 分组，确认三个值都能看到。因为包名和签名没变，老用户可以直接覆盖升级，二维码也可以长期复用，只需要在活动结束后停用对应参数。

图 4：多包名适合共存，多渠道适合统计。两条路不要混着走。

七、扫码失败排查：从系统解析结果往回找

排查链接问题，最有效的方法不是反复改二维码，而是看系统实际解析到了什么。Android 收到一个链接后，会按协议、域名、路径去匹配已安装应用清单里的 intent-filter。匹配到了就拉起对应页面，匹配不到就交给浏览器。知道这个顺序，就能把“扫不开”拆成“没匹配到”“匹配到旧应用”“匹配到了但页面报错”三种情况。

如果系统把链接交给了浏览器，先检查新包的清单里有没有对应的 intent-filter。自定义协议的 scheme 和 host 是否写对，路径前缀是否匹配；HTTPS 链接是否声明了 autoVerify，域名是否和 assetlinks.json 一致。改包时如果只改了包名，没有动清单里的链接声明，理论上还能匹配；但如果链接本身指向旧域名，或者新包把旧声明删了，就会落到浏览器。

如果链接打开了旧应用，说明旧包仍然注册着同一个协议，而且系统没有把新包作为首选。自定义协议本身没有强制归属，多个应用注册同一 scheme 时，系统可能弹出选择框，也可能按用户之前的选择直接打开。要彻底解决，最稳妥的是使用已验证的 App Links，让域名和签名绑定到唯一应用；如果只能用自定义协议，就给新包换一个独有的 host，并确保旧包不再声明它。

如果安装时提示签名不一致，不要急着重装。先确认旧包是用哪套密钥签的，新包是不是换了密钥。同包名、不同签名无法覆盖，这是系统的硬规则，不是工具的问题。能用原密钥就用原密钥；必须换密钥，就要设计卸载重装或迁移方案。内部应用可以集中处理，外部应用要提前公告，并把旧包的下载入口保留一段时间。

如果应用能装能开，但分享失败，重点查开放平台。分享通道通常要求登记包名和签名，有些还要求登记回调页面。改包后包名或签名变了，登记信息没变，就会出现“面板能弹、发送失败”或“发送成功、回调不回来”。核对时不要只看后台显示的应用名，要展开看包名和签名摘要，逐字对照打包结果。

如果渠道统计为空，先看最终落地页的 URL，再看应用内的渠道读取逻辑，最后看渠道包配置。很多问题出在短链跳转：短链服务把参数吃掉了，或者落地页重定向时只带了路径没带查询串。把二维码里的原始 URL 复制到浏览器，一步步观察地址栏变化，比在统计后台反复刷新有效得多。

如果二维码扫不出来，先用另一台手机扫同一张图，再放大扫，再换扫码应用。三种方式都不行，才怀疑图片。能扫出来但打开错误页面，说明图片没问题，问题在链接内容。把这两个层面分开，能避免在设计和开发之间来回甩锅。

现象	核对动作	通过标准
浏览器打开，应用没反应	看清单 intent-filter、App Links 状态	链接能拉起目标页面
提示应用未安装	对照项目页包名与链接里的包名	两处完全一致
打开旧应用	检查旧包协议声明与默认打开设置	只拉起新应用
安装冲突	比对证书 SHA-256 指纹	覆盖安装成功
分享失败	开放平台包名与签名登记	分享与回调都正常
渠道为空	最终 URL、跳转链路、渠道包配置	后台能按渠道分组

排查时建议只改一个变量。一次同时换包名、换签名、换域名、换二维码，出了问题根本不知道是哪一步导致的。正确顺序是：先让新包在本地装好、能启动；再让链接能打开新包；再让参数能传到落地页；最后才批量生成二维码。每一步都留下一个可回退的版本，出了问题能退回去。

如果同一个包一天之内改了好几次，要给每次产物编一个能看懂的版本标记。不要用“最终版”“最终版2”这种命名，时间一长没人分得清。可以用“日期加需求序号”的方式，例如 1024-01、1024-02，和 history.ini 里的需求记录对上。二维码物料也标同一个版本，出问题时能迅速定位是哪一版对应的链接。

智能修改电脑版的日志体系对排查很有用。打包过程中的回编、对齐、签名、校验都会写进 pack.log，反编译输出在 apktool.log，异常还有 error.log。分享失败时，先把打包结果里的签名指纹和 open 平台配置对照；扫码失败时，先把项目页的包名和二维码文本对照。日志不是给“看起来专业”用的，它是把口头描述变成可核对事实的工具。

八、上线前的对齐清单：十二项逐条打勾

把前面的内容压缩成一张清单，放在每次改包交付前过一遍。清单不需要很长，但每一项都要有明确的证据，不能只凭“应该没问题”。建议把这张清单和项目目录一起归档，下次换人接手时，能直接看到上次是怎么核对的。

1. 包名已冻结，项目页显示的值与安装后系统应用信息一致。
2. 版本号已递增，覆盖安装不会提示降级。
3. 签名文件已确认，证书 SHA-256 指纹已记录。
4. 打包日志里 verify 通过，签名方案符合目标系统要求。
5. App Links 的 assetlinks.json 已更新包名和指纹，域名可访问。
6. 应用市场或下载页的包名、版本号、图标已同步。
7. 自定义协议的 scheme、host、路径与代码一致，旧包不再抢占。
8. 邀请链接同时提供 HTTPS 落地页和唤起入口，未安装时有下载指引。
9. 渠道参数命名统一，最终落地页能读到，跳转不丢参数。
10. 二维码由最终链接生成，原始文本已归档，三种设备状态都实扫过。
11. 微信、QQ 等分享通道已用新包实测，登录、支付、推送回调正常。
12. 旧包保留一段时间，回滚包和回滚说明放在团队能找到的位置。

这张清单里，最容易被跳过的是第五项和第十项。assetlinks.json 藏在网站目录里，平时没人看；二维码实扫又觉得“我自己扫过就行”。但这两项恰恰是外部用户最先接触到的环节。把域名根目录的验证文件当成发布物的一部分，把二维码当成需要验收的代码，问题会少很多。

建议再建一个“证据文件夹”，里面放四样东西：最终二维码的原始文本、verify 输出的签名指纹、扫码验收的截图或记录、以及本次使用的链接清单。四样东西和成品 APK 放在一起，按版本号命名。下次有人问“这个二维码到底指向哪里”，打开文件夹就能回答，不用去翻聊天记录。证据文件夹不需要多漂亮，能对上号就行。

图 5：二维码文本、签名指纹、验收记录和链接清单放在一起，才是一份能复查的交付物。

还有一个组织层面的建议：包名、签名、渠道参数这三类信息，不要只存在某个人的聊天记录里。至少有一份团队共享的表格，记录当前版本的包名、版本号、签名指纹、二维码文本、落地页地址和负责人。每次发版更新一行，旧行保留。这样即使负责人休假，其他人也能接上。

如果是给客户交付，清单还可以再加一项：授权说明。写清这个应用是客户自有或已获授权，改包范围是什么，哪些内容不在本次范围内。听起来像形式，但真出现争议时，这一页纸能省掉很多解释。尤其是在品牌、渠道、用户数据交织的项目里，边界清楚对双方都好。

清单的意义不是增加流程，而是把“我记得”变成“我核对过”。链接问题最贵的成本，往往不是修，而是重新印、重新发、重新解释。

九、用户评价：他们踩过的坑，后来怎么绕过去

这些评价里的共同点，不是“工具多神奇”，而是“先核对再发布”。包名、签名、渠道参数都是可以写下来、对得上的事实。把它们从记忆里搬到表格里，从口头交接变成文件交接，链接问题就会从“玄学”变成“流程”。

十、把对齐做成习惯：工具负责改，人负责核对

改包工具能把反编译、修改、回编、对齐、签名、校验串成一条流水线，但它不能替你决定“这个包应该叫什么、由谁签、发给谁”。这三件事是产品和运营的决策，必须由人来定。工具的价值，是让决策之后的操作变得可重复、可验证，而不是让决策本身变得随意。

智能修改电脑版把包名、版本号、签名指纹、打包日志都放在项目里，项目列表和详情页能直接看到；需要改链接、改渠道配置、改分享回调时，用一句中文需求就能发起，附件还能把对照表一起带进去。改完自动回编、对齐、签名、校验，产物和日志留在项目目录，下一次复查有据可依。这就是“只需说话，就能让应用变成你想要的样子”在链接场景里的具体含义：话要说清，结果要能验。

如果只能记住一句话，就记住这个顺序：先冻结包名，再确认签名，再统一渠道参数，最后生成二维码。顺序对了，大部分问题在生成二维码之前就已经暴露；顺序错了，二维码就会变成背锅的那张图。

更多改包流程、签名设置和项目管理的说明，可以在安卓修改大师智改工坊的介绍页查看：https://www.apkeditor.cn/ai-version.aspx。官网 www.apkeditor.cn 上还有其它使用技巧和版本说明。

合规提醒再说一次：本文的方法只适用于自有版权或已获授权的应用。请勿用于破解他人付费应用、去除授权校验或绕过安全机制，也不要把改包能力用在来源不明的商业软件上。二维码和邀请链接连接的是用户信任，这份信任值得用更严谨的流程去对待。

只需说话，就能让应用变成你想要的样子——但说完之后，请把包名、签名、参数三件事对上。对上了，二维码才只是一张图；对不上，它就是一次事故的入口。

智能修改安卓版 · 手机与平板本地改包 · 仅用于自有版权或已获授权的应用