Shopify卸载应用后还有代码？按集成方式检查残留

卸载应用不只是解除授权，也不保证店铺回到安装前的完整状态。Shopify会清理相应平台管理资源，但手工写入主题的代码、外部订阅和应用数据有各自处理方式。看到某个域名还在请求，先确认来源，不能立即断定卸载失败。

先分清是哪种集成

主题应用扩展UX文档明确说明关联区块自动完整移除；ScriptTag资源文档说明其按创建应用归属并随卸载移除。商家卸载帮助则提示部分应用写入主题的代码不自动删除。这三种说法对应不同机制，不应互相覆盖。

先做数据和依赖安排，再卸载

确认应用负责哪些流程、数据能否导出、是否管理库存位置，以及是否需要开发者配合。按原厂卸载帮助处理实际库存和自动化依赖；备份主题文件不能恢复应用后台数据。应用外部收费应单独取消，当前账期是否仍有费用也要核。

卸载是店铺级操作，不是在主题副本内做一个只影响预览的动作。主题副本用于修改主题代码、检查和回退；不能把它当成独立测试店。旧主题留有手工片段时，也要记录，避免未来重新发布旧主题时恢复无用请求。

确有手工残留时，按引用关系清理

1. 保存当前主题与相关文件、应用说明及正式页面请求，记录具体版本和配置。
2. 搜索已确认的应用标识、域名、snippet名称和调用位置，核谁仍引用它。文件名相似或同一域名并不足以判定全部归属。
3. 在主题副本中同时处理获确认的调用与专用资源；共享片段先拆清依赖，不用全局替换删除所有同名片段。
4. 对于shopify://apps/等配置先核当前状态，不按字符串命中就批量删JSON。自动移除的扩展不需要预设手工删除步骤。
5. 核编辑器、公开页面、关键购买操作及相关请求，确认没有新增Liquid错误、缺样式或错误事件。

原厂脚本审计建议提供源码、Coverage和请求检查方向；实际删除仍应基于当前依赖。仅主题文件里搜不到，不证明没有其他入口；仅有请求，也可能来自另一个仍在使用的应用或平台配置。

ScriptTag退役和卸载不是同一件事

截至2026年10月22日，店面ScriptTag时间表规定2026年10月1日起不能创建或更新，现有资源继续运行；2027年3月1日起停止向店面注入。迁移到app embed后需按主题启用。不要把这份计划误写成所有script标签现在都不执行，也不要用它替代所属应用卸载后的实际检查。

怎么判断这次处理完成了

重新打开真实公开页面，核HTML、DOM、请求发起链及必要功能；覆盖受影响模板、市场、同意状态和关键操作。相关应用停止的功能应有预期安排，保留的统计与购买事件则应验证。性能按同条件比较，数据与订阅另看实际状态，不能由“没有报错”推断全部恢复。

后续应用选择可用兼容性与退出成本清单，复杂脚本归属沿请求审计继续。清理目标是移除确认无用的部分并保持必要能力，不是让主题文件或Network看起来越短越好。