分享出去那条链接点不开：跳转声明与改包的三处连带

有一类问题，只有改过包的人才会遇到：应用本身好好的，分享出去的那条链接却打不开了。别人在聊天里点一下，要么跳到一个空白页，要么提示「暂不支持打开」，要么干脆什么反应都没有。

奇怪的是，装这个应用的手机上，有些链接能打开，有些不能；换一台手机，能打开的那些也打不开了。看起来像玄学，实际上是包里的一段声明和一个校验结果在起作用。

这一篇讲链接：一条链接点下去系统在做什么、应用怎么声明自己能接、改包之后为什么失效、以及分享出去的内容本身要不要跟着改。官网是 www.apkeditor.cn。

一、一条链接点下去，系统在做什么

点一条链接，看起来是一个动作，实际上系统内部走了好几步。理解这几步，后面所有「打不开」都能对上号。

第一步，识别。系统先看这串字符长什么样：如果是 http 或 https 开头，就当成网页链接；如果是自定义的协议前缀，比如某个应用自己的 scheme，就当成「可能由某个应用处理」。这一步只看前缀，不看内容。

第二步，查找。系统去问所有装了的应用：谁能处理这个链接？每个应用在自己的一份声明里写着「我能接什么样的链接」，系统把这些声明汇总起来，找出候选者。

第三步，校验（只有 http/https 会走这一步）。如果好几个应用都说自己能接同一个域名，系统需要判断谁才是真正的主人。判断方式是去那个域名下取一份文件，看里面有没有登记这个应用的签名。登记了，就默认用它打开；没登记，就退回到「让用户选」或者「用浏览器打开」。

第四步，打开。选定应用之后，把链接连同一段附带的参数交给它。应用从里面解析出「用户想看哪个页面、哪条内容」，然后跳到对应界面。如果解析失败，用户看到的就是首页，或者一个空白页。

四步里，第一步和第二步靠包里的声明，第三步靠服务器上的一份文件加签名，第四步靠代码。改包会同时动到前三步，这就是为什么改完之后链接会失效。

还有一个容易忽略的点：第四步失败的时候，系统不会报错。链接已经交给了应用，后面跳到哪一页是应用自己的事。所以「点开之后停在首页」这种情况，看起来像成功，实际上是解析失败。

把这些步骤记住，排查就有了顺序：先看系统有没有把链接交给应用，再看应用有没有跳到正确的页面。这两个问题分属完全不同的原因，混在一起查会绕很久。

二、两种链接：自定义前缀与域名链接

应用能接的链接，只有两大类。它们的机制、成本、可靠程度都不一样。

第一类，自定义前缀。形如「某前缀://某路径」，前缀由应用自己定，只要不和别人撞就行。它的优点是简单：不需要服务器、不需要校验、声明一行就能用。缺点是它只在「链接被当作文本处理」的场合有效，很多内置浏览器会拦它。

第二类，域名链接。形如「https://某域名/某路径」，用的是普通的网页地址。它的优点是通用：任何地方都能点，包括聊天工具、邮件、短信；装了应用就用应用打开，没装就用浏览器打开，体验完整。缺点是它需要校验，也就是第三步那个文件。

两类链接在实际项目里经常同时存在。自定义前缀用于应用内部跳转和已装应用之间的唤起，域名链接用于对外分享。这个分工是合理的，但改包的时候要分别处理，不能只改一类。

有一个很现实的情况值得说：很多聊天工具的内置浏览器不允许直接唤起自定义前缀。用户点一下，要么提示「已复制链接，请在浏览器中打开」，要么什么都不发生。这不是应用的问题，是环境限制。所以对外分享的链接，尽量用域名链接，而不是自定义前缀。

反过来，域名链接也有它的限制：如果校验没通过，系统会把链接交给浏览器，用户看到的是网页而不是应用。这种「降级」在体验上不算失败，但在功能上可能是：需要登录、需要拍照、需要本地数据的页面，在浏览器里做不了。

所以选择哪一类，取决于这个链接的用途。对外分享、需要被任何环境点开的，用域名链接并做好校验；应用内部跳转、只有已装用户会用的，用自定义前缀最省事。两类混用不是错，但要清楚每一个链接属于哪一类。

三、包里怎么声明：一段过滤条件

应用能接什么链接，写在包里的一个声明块里。它的结构不复杂，但几个字段各有各的坑。

第一个字段是动作。声明「我要处理「打开链接」这个动作」。这个字段写错了，整个声明就无效，而且不会有任何提示。

第二个字段是类别。其中有一项是必须的，表示「这个链接可以从外部唤起」。漏了这一项，链接只能从应用内部跳，外面点不进来。这是最常见的漏写之一。

第三个字段是数据。它描述「什么样的链接归我」，通常由三部分组成：协议前缀、主机名、路径前缀。三者组合起来才是完整的匹配条件。

这三部分里，路径前缀最容易被写错。它有两种匹配方式：一种只匹配路径的开头，一种要求完全一致。写成了完全一致，那么带参数的链接就匹配不上，表现是「有的链接能开，有的不能」。

第四个字段是自动校验。这个是给域名链接用的，声明「我这个应用要和这个域名绑定，请系统去校验」。加了它，系统才会走第三步；不加，系统永远让用户选或者用浏览器打开。

还有两个细节。一是同一个应用可以声明多个链接条件，分别对应不同的路径，比如「商品详情」和「订单详情」各一条。二是声明的顺序不影响匹配，系统只看条件是否满足，不看谁写在前面。

这些字段加起来，就是一段不太长但很容易写错的配置。写错的表现都一样：链接点不开，或者打开之后停在首页。所以在改包场景里，凡是动过包名、签名、域名，都要把这段配置重新看一遍，而不是假设它没变。

四、改包之后，链接为什么失效

改包会动到链接机制的三个地方，每一处都能单独造成失效。

第一处，包名。自定义前缀里常常带着包名或者包名的一部分，因为这样天然不会和别人撞。包名一改，前缀跟着变，所有按旧前缀生成的链接就都失效了——系统找不到能处理它的应用，用户点开没反应。

更麻烦的是，已经分享出去的旧链接改不了。它们在别人的聊天记录里、在打印出来的物料上、在公众号的历史文章里。这时候唯一的办法是新应用同时声明旧前缀，让它既能接新链接，也能接旧链接。

第二处，签名。域名链接的校验，比的是「这个域名下登记的应用签名」和「当前装的这个应用的签名」。签名换了，校验就过不去，系统会退回浏览器打开。

这一处的表现比第一处温和：链接还是能点开，只是打开的是网页而不是应用。很多人因此以为「没问题」，但功能其实是降级的——需要登录的页面要重新登录，需要拍照的页面拍不了。用户感受到的是「这个应用怎么老是跳到浏览器」。

第三处，声明本身。有人改包时觉得某些声明没用，顺手删了；或者换了构建配置，某个声明没被打进去。结果就是「什么都没改，链接就是打不开了」。这种最难查，因为变化不在代码里，在打包过程里。

三处里，第一处和第三处是「有没有」的问题，第二处是「对不对」的问题。排查时先确认声明还在（看包，不看代码），再确认前缀有没有变，最后确认校验过不过。这个顺序能覆盖绝大多数情况。

还有一个连带影响值得提前想到：链接失效往往不是全失效，而是一部分失效。因为不同的链接可能用了不同的机制：有的走自定义前缀，有的走域名，有的两个都声明了。所以验收不能只点一条链接，要把每一类各点一条。

五、域名校验那一步，到底在比什么

域名链接能不能用应用打开，全看这一步。它的机制很简单，但对不上就怎么都不行。

比的是一个签名指纹。应用的签名可以算出一个指纹，这个指纹是公开的、固定的，同一个签名算出来永远一样。服务器上放一份文件，里面写着「这个域名认可哪些指纹」，系统去取这份文件，比对当前装的这个应用的指纹在不在里面。

三个地方必须完全对上，缺一个都不行。第一是域名：文件要从那个域名下取，而且是在一个固定的路径上。第二是指纹：文件里写的指纹必须和当前应用的一致。第三是包名：文件里通常还会写包名，包名对不上也不算。

这三个地方，正好对应改包会动的那三样。改了包名，第三条不过；换了签名，第二条不过；换了域名，第一条不过。任何一条不过，系统就认为「这个应用不是这个域名的主人」，链接交给浏览器。

有一个细节经常被误解：校验不过不是「错误」，是「降级」。系统不会提示用户「校验失败」，它只是安静地把链接交给浏览器。所以从用户角度看，链接是「能打开的」，只是打开的地方不对。

这也解释了为什么这类问题容易被忽略。如果用浏览器打开也能完成，用户不会报；只有那些「必须在应用里做」的页面，才会变成投诉。而那些页面恰恰是最重要的：支付、上传、审批、扫码。

还有一点值得提前知道：这份文件是可以一次配好的，不需要每次改包都动。它固定在服务器上，只要签名不变、包名不变，就一直有效。所以真正需要小心的是「改包的时候顺手改了签名」这件事，它会让一份本来有效的配置突然失效。

六、自定义前缀的四个坑

自定义前缀看起来最省事，但它有四个坑，每一个都能让链接点不开。

第一个坑，前缀撞车。两个应用声明了同一个前缀，系统不知道该给谁，于是弹一个选择框让用户选。用户选错了，链接就跳到了别的应用，表现是「点了没反应」或者「打开了一个奇怪的东西」。避免的办法是把包名编进前缀里，天然不撞。

第二个坑，被内置浏览器拦。前面提过，很多聊天工具的内置浏览器不允许直接唤起自定义前缀。它可能提示「已复制，请在浏览器打开」，也可能什么都不做。这种情况改包解决不了，只能改用域名链接。

第三个坑，大小写。理论上协议前缀应该统一用小写，但实际实现的处理并不一致。同一串前缀，写成大写和小写，在不同系统版本上的结果可能不同。规则很简单：全部小写，不要混用。

第四个坑，链接里的参数没转义。自定义链接经常带着参数，比如「要打开哪条记录」。如果参数里本身含特殊字符而没处理，解析的时候就会截断，结果是「跳到了页面，但内容不对」或者「跳到了首页」。

四个坑里，前两个是「能不能唤起」，后两个是「唤起之后对不对」。排查时也是两个问题分开看：先确认系统有没有把链接交给应用，再确认应用有没有跳到正确的页面。

还有一个实践建议：把前缀当成一个常量，只定义一处。散落在代码各个角落的前缀，改包时必然漏改，而漏改的表现是「一部分链接能用，一部分不能」。这种半好半坏的状态，比全坏更难查。

七、第一个实例：白牌改包名，分享链接全失效

我们自己维护的门店经营管理平台，给一个新客户做白牌交付，按规矩改了包名、换了名字和图标。

交付当天，客户那边反馈：店员之间互相分享的「调货单」链接，点开全部没反应。而在旧品牌那边，同样的操作一直正常。

查下来原因很直接：分享链接用的是自定义前缀，前缀里带着包名。包名一改，前缀跟着变，新应用声明的是新前缀；而链接是旧应用按旧前缀生成的，系统在新应用里找不到能处理它的声明，于是什么也不做。

更麻烦的是那些旧链接并没有消失。它们在店员之间的聊天记录里，在群里，在打印出来的单据上。这些人已经装了新应用，但手里的链接还是旧的。

当时有两个选择。一是让新应用同时声明旧前缀，这样新旧链接都能接；二是把分享功能改成生成新前缀的链接，旧链接就当废了。我们选了第一条，因为旧链接的数量比想象中大得多。

第一条的做法很简单：在声明里再加一条，前缀写旧的。代价是「旧前缀归我」这件事要独占，如果旧应用还装在同一台设备上，两个应用会抢，系统会弹选择框。所以这条策略的前提是「旧应用已经不用了」。

这件事之后，我们给白牌交付加了一条：把「链接前缀」列进交付清单，和包名、签名、版本号放在一起。因为它同样会随包名变化，而且它产生的东西（链接）会留在外部世界里，改不回来。包名改了只影响装的人，前缀改了我影响已经分享出去的所有东西。

八、第二个实例：换了签名，链接一律跳浏览器

另一个实例是现场巡检端。有一次因为签名文件的管理问题，重新生成了一份签名，之后发的包都用新的。

装上去一切正常，功能都在。问题在一周后才被发现：客户在群里发的工单链接，同事点开都是在浏览器里打开网页，要重新登录。

原因是域名校验。服务器上登记的是旧签名的指纹，新签名不在里面，系统判断这个应用不是这个域名的主人，于是把链接交给浏览器。

这个失败形态特别容易让人误判。链接「能打开」，只是打开的地方不对。用户不会说「链接坏了」，他会说「怎么又要登录」「怎么在网页里传不了照片」。报上来的问题描述和真实原因隔了很远。

修法不难：把新签名的指纹加到服务器那份文件里。但有一个坑——旧签名的指纹不能删。因为还有一批用户装着旧签名的包，删了他们的链接也会失效。所以过渡期要两个指纹并存，等旧包的用户都升级完了再清理。

这件事真正的教训不在技术，在流程。签名的变更没有被当成一次「会影响链接和第三方身份」的变更来处理，它被当成了一个纯粹的技术操作。而签名这个东西，牵动的远不止安装。

后来我们的做法是：签名相关的变化必须单独走一次检查，检查项包括安装覆盖、域名校验、第三方登录、支付回调、推送。五项，每一项都对应过一个真实的问题。签名的稳定性，是所有这些能力的地基。

九、分享出去的不只是链接

改包时容易只盯着「链接能不能打开」，而分享出去的内容其实有三层，三层都要看。

第一层是链接本身。前缀或域名对不对，能不能被正确唤起。这一层前面讲完了。

第二层是文案。分享出去的标题、描述、图片。这些通常在生成分享内容的时候拼出来，里面的应用名、品牌名、口号，都是写死的字符串。改包时如果不改，用户分享出去的东西还是旧品牌的名字，而这条内容会被转发到很多地方。

第三层是落地页。没装应用的人点开链接，看到的是网页。这个网页可能是应用自己的，也可能是第三方的。如果是自己的，它的内容、配色、下载引导都要跟着换；如果是第三方的，那至少要确认它还能打开。

三层里，第二层最容易被忽略，因为它不在界面上。你打开应用，点分享，看到的预览是对的——因为预览往往是本地拼的。但发出去之后，对方看到的是从服务端取的那一份，可能还是旧的。

验证第二层的办法很简单：真的分享一次，发给另一台设备，看对方收到的是什么。自己给自己发不算，因为可能命中缓存。用另一台设备、另一个账号收，才能看到真实效果。

第三层常被忽略的原因更简单：测试的人都装了应用。没装应用的人点什么、看到什么，从来没人验过。而这恰恰是新用户第一次接触这个品牌的方式。

所以分享这一块，验收要覆盖三种人：装了新应用的人、装了旧应用的人、什么应用都没装的人。三种人点同一条链接，应该得到三种都合理的结果。只验第一种，等于只验了自己的同事。

十、在聊天工具里点链接，会发生什么

链接真正被点开的地方，往往不是浏览器，而是聊天窗口。这里的规则和浏览器不一样，值得单独说。

最常见的情况是内置浏览器。很多聊天工具不把链接交出去，而是在自己的窗口里打开一个网页。这时候域名链接可以正常显示，但「装了就进应用」这一步可能被跳过——用户看到的是网页，即使他装了应用。

不同应用的处理方式差别很大，而且会随版本变化。所以「我这边能跳」不能作为验收结论。必须拿真实的目标环境试：客户常用的那个聊天工具、那个版本。

自定义前缀在多数内置浏览器里是唤不起的。表现可能是提示一句「已复制」、可能是空白、也可能完全没反应。这不是 bug，是环境有意为之，因为随意唤起本地应用有风险。

还有一类情况是「安全提示页」。某些环境会在真正打开之前先显示一个中间页，写着「即将离开当前页面」，需要用户再点一次。这一步会显著降低打开率，用户以为是广告，直接退回去。而这条链路上没有任何一处能让你知道用户在这里走掉了。

所以对外分享的链接，设计时要接受一个现实：它会在一个你控制不了的环境里被打开。能做的只有三件事：用最通用的形式（域名链接而不是自定义前缀）；落地页本身要能独立使用，不要依赖应用里的状态；在页面上给一个明确的「用应用打开」按钮，把选择权交给用户。

第三件事最实用。与其想办法自动唤起，不如把「打开应用」做成一个显眼的按钮。自动唤起失败时用户会困惑，一个按钮至少让他知道还有别的路。这条路不优雅，但它可靠。

十一、验收七项：三种人、两种环境

链接这一类改动，验收的关键不在于「点一下能开」，而在于「在不同的设备和环境里，各自得到合理的结果」。下面七项，缺一项就等于漏一条路径。

第二项最容易被忽略。改包之后，旧链接一定还存在，它们在聊天记录、邮件、打印物料里。新应用能不能接住它们，是一个必须回答的问题。接不住也要有提示，而不是「点了没反应」。

第四项对应的是「新旧共存」的过渡期。旧版本的用户点了新链接，最常见的结果是打开首页或者报错。如果能在应用里识别出「这个链接需要新版本」，给一句升级提示，体验会好很多。

第六项是区分「跳对了」和「跳到了」的唯一办法。只验不带参数的链接，永远发现不了参数解析的问题。而参数解析恰恰是改包之后最容易坏的一环。

第七项看起来和链接无关，但它决定了分享出去的东西像不像一个正经产品。一条链接点开是新的，预览里写着旧品牌名，用户会以为这是钓鱼。

十二、七个问题，都和「点了没反应」有关

问题一：链接点了完全没反应，是什么原因？三种可能：包里没声明能接这类链接；前缀或域名对不上；在某个不允许唤起的环境里。先换一个环境再试，能区分出是环境问题还是包的问题。

问题二：链接能打开，但停在首页，怎么办？说明唤起成功了，但参数没解析出来。检查链接的路径和参数格式，以及应用里解析的那段代码是不是还在。

问题三：为什么有的手机能跳，有的不能？看两件事：装的是哪个包（新旧签名、新旧包名），系统版本是什么。不同系统版本对域名校验的处理不完全一样，旧版本可能更宽松。

问题四：域名链接一定要校验吗？不校验也能用，但系统会在打开前让用户选一次，或者直接用浏览器。校验的意义是「不用问，直接进」，它决定的是体验，不是能不能用。

问题五：改了包名，旧链接怎么办？两条路：新应用同时声明旧前缀，或者接受旧链接失效并给提示。前者需要旧应用不再占用那个前缀，后者要让用户知道为什么打不开。

问题六：能不能在网页上直接唤起应用？可以，但取决于环境。很多内置浏览器会拦。更可靠的做法是在页面上放一个按钮，让用户主动点，而不是自动跳。

问题七：分享出去的链接，怎么确认是新品牌？发给另一台设备、另一个账号，看对方收到什么。自己给自己发不算，因为可能命中本地缓存。

十三、一次返工的账：一条链接，两天排查

把第七节那个白牌交付的事故算一遍，会看到很典型的结构。

修复成本：半天。在声明里加一条旧前缀，重新打包，验证新旧链接都能接。排查成本：一天半。先怀疑是客户手机的问题，再怀疑是聊天工具的问题，最后才想到去看分享链接长什么样。而这一步，本来应该是第一步。

为什么会绕？因为「点了没反应」这个现象不提供任何线索。它不报错、不提示、不留痕。人面对这种反馈，本能是先试一次、再试一次，然后开始猜。而猜的顺序，通常是从最不熟悉的部分开始。

真正省时间的做法是把链接本身当成第一个证据：它长什么样、前缀是什么、是谁生成的、和当前应用声明的是不是一致。这四个问题，两分钟能问完。

这件事之后，我们把它变成了一个检查动作：凡是改包，先找出三条真实分享过的链接，记下它们的样子，改完之后逐条点一遍。三条链接的成本是五分钟，它能提前暴露掉绝大部分问题。

还有一个更根本的教训：链接是少数「会产生外部残留物」的改动。包可以重发，版本号可以再加，但一条已经发到群里的链接改不了。所以这类改动要在动手之前想清楚，而不是发完之后再补。

我们现在的做法是，在改包清单里把「链接前缀」和「包名」「签名」并列，三项都要确认。这三项有一个共同点：它们都决定了「外面的世界怎么找到这个应用」。

十四、推送、扫码、通知点击，走的也是同一条路

分享链接只是入口之一。改包之后失效的，往往还有另外几个入口，而它们比分享更不容易被想到。

第一个是推送通知的点击。用户收到一条推送，点开之后应该跳到对应的页面。这条跳转的实现方式，通常是把一段带参数的标识附在通知里，用户点的时候由应用自己解析。它不经过系统的那套声明，所以包名和签名变化不会直接影响它——但如果推送服务绑定了包名或签名，那就连推送都收不到了。

第二个是扫码。二维码里通常就是一条链接，扫出来之后和点分享链接完全一样。所以前面说的所有问题，扫码都会遇到一遍。区别在于：二维码常常已经印在物料上、贴在墙上，比聊天记录更难改。

第三个是短信或邮件里的链接。这类环境比聊天工具更封闭，唤起应用的成功率更低。常见的做法是让链接直接打开网页，网页上再给一个「打开应用」的按钮。这个组合最稳。

第四个是第三方回调。支付、登录、分享到第三方，都会在完成之后回调到应用。回调地址里往往带着应用的身份信息，包名或签名一变，第三方那边可能就不认了。表现是「付了钱但应用里没反应」，或者「登录授权完了回不来」。

这四个入口有一处共同点：它们都不在你的应用里。你改的是包，但断的是外面那些已经配置好的东西。所以改包影响的边界，比包里能看到的要大。

一个具体的做法：改包之前，把所有「外面的东西」列一遍——推送平台的配置、第三方平台的回调地址、印出去的二维码、发出去的链接、公众号里的历史文章。列完之后，在包里核对一遍哪些用到了包名或签名。这一步能把大部分连带问题提前发现。

还有一类容易被忘的：后台管理系统里配置的下载地址。客户从后台点「下载」，拿到的是某个固定地址的安装包。改包之后如果换了文件名或者存放位置，这个地址就失效了，而它往往写在别处，不在应用里。这一条几乎每次改包都会踩一次。

所以一个更准确的说法是：改包不是一个孤立动作，它会影响一整条链路上所有依赖「应用身份」的地方。这条链上有安装、有链接、有推送、有第三方、有物料。把这条链画出来，比记住一堆细节有用。

最难处理的是已经印出去的二维码。物料不会因为改包而重印，墙上那张贴纸会一直用到下一次活动。这时候唯一可行的做法是让新应用继续认得旧前缀，同时把二维码指向的落地页也保留下来，不要急着下线。保留多久？至少留到这一批物料全部用完。

这件事有一个通用的判断标准：凡是已经离开你的手的东西，都不能假设它会被改掉。聊天记录里的链接、印出去的二维码、第三方平台里配置的地址、客户后台里的下载按钮，都属于这一类。它们只会在你的改动之后，安静地变成一行死链。

所以改包这项工作的边界，最好在动手之前就画清楚：包里的部分，改完就能验；包外的部分，只能提前想到并保留兼容。把两件事分开处理，比混在一起试要快得多。

十五、把「别让链接失效」写成一句能执行的话

「改包的时候注意一下外链，别让分享出去的链接打不开」——这句话听起来很负责，实际上什么也没交代清楚。

一句能执行的话：这次白牌交付改包名，链接前缀也要跟着改；新应用里除了声明新前缀，再加一条声明旧前缀，让已经发出去的旧链接还能接住；域名不变，所以服务器上那份校验文件不用动；签名沿用原来那一份，不许重新生成；改完拿三条真实分享过的旧链接各点一次，再用一台没装应用的设备点一次，确认落地页能打开。

这句话里有五个关键信息。第一，前缀要跟着包名改，明确说出来，而不是让人自己想到。第二，旧前缀要不要保留，这是一个必须由人决定的事，写清了才不会各行其是。第三，域名和校验文件要不要动，写清「不用动」，能避免有人顺手去改。第四，签名不能换，这一条最容易被忽略，也最贵。第五，怎么验，写清三条真实链接加一台干净设备。

还有两条值得加进去。一是「分享文案里的品牌名要一起改」，因为这段文字往往写死在生成分享内容的代码里。二是「出问题时的排查顺序」：先看链接长什么样，再看包里有没有声明，最后看校验过不过。三步，写成一行，出事时不用现想。

我们内部现在的改包清单，关于链接的部分有四行：前缀、旧前缀、域名与校验、真实链接验证。四行加起来不到五十个字，但它们覆盖了几乎所有会出问题的位置。

值得多说一句的是「不许重新生成签名」这一条。它不是技术要求，是纪律要求。因为重新生成签名在技术上没有任何障碍，一条命令的事；但它的后果会扩散到安装、校验、第三方登录、支付回调、推送五个地方。这种事情必须用「不许」来管，而不是用「尽量不要」。

十六、三句话，把这件事收住

第一句：链接能不能进应用，靠的是包里的一段声明；进得去之后跳到哪一页，靠的是代码。这两件事分开查，能省一半时间。「点了没反应」和「点开停在首页」是两个完全不同的问题。

第二句：域名链接要校验，校验比的是域名、签名、包名三样。改包恰好会动其中的包名和签名，所以改包之后链接失效不是意外，是必然——除非你提前处理。

第三句：已经分享出去的链接改不了，所以要么让新应用接住旧前缀，要么给用户一个明确的提示。「点了没反应」是最差的处理方式，因为它连「为什么」都不给。

三句合起来是一件事：链接是应用伸出到外部世界的一只手，改包的时候，这只手很容易被一起改掉。而伸出去之后，它就不完全归你管了。所以每一次动包名或签名，都要把这只手重新接一遍。

十七、附：一页速查

下面这张表把全文压成八行，改包或者排查「链接打不开」的时候可以对着看。

最后补一句：上面这些确认项，最好和改包放在同一条流程里。改完声明、回编、对齐签名、真机预览，一次走完，比发出去之后再回头补要省事得多。安卓修改大师智改工坊把这些环节收在一次操作里，产品介绍页在 这里。

十八、用过的人怎么说

这一篇里的两个实例，都是我们自己维护的应用：一个门店经营管理平台，一套现场巡检端。链接这类问题的特点是：改动很小，影响很远。一行声明、一次签名，就能让一批已经发出去的链接全部失效，而这些链接不在你的包里，也不在你的控制下。

合规提醒：本文所有实例均针对自有版权或已获授权的应用，用于企业内部维护、白牌交付与合法定制。请勿通过声明他人域名或前缀劫持链接、冒用他人应用身份，也不要为未授权应用配置可唤起他人服务的链接。改包前请确认你对目标应用、所用域名以及相关签名材料拥有相应权利。

一条链接是应用伸到外面的一只手。用户不认识你的包名，也不关心你的签名，他只知道点了一下，然后就该看到想看的东西。

安卓修改大师智改工坊能做的，是把改包之后那一串动作一次落到位：声明、回编、对齐签名、真机预览，改完当场就能拿旧链接点一遍。说清楚，就够了。