macOS 27 升级说明
应用打不开？先按下面的步骤修复
如果你曾在 AppPorts 的旧版或测试版中同意重签名，升级到 macOS 27 后，微信等应用可能无法从 Finder / Dock 打开。先还原旧方式迁移的容器数据，再恢复原始签名或从官方渠道重装。不要删除数据目录，也不要再次重签名。 签名错误本身不代表聊天记录等数据已经损坏。
修复
在 AppPorts 应用列表中，找到带「签名已替换」标记的应用，直接点行内的 「修复」；也可以右键选择「查看修复步骤」。不需要先运行终端命令。
本文的新引导对应当前开发版本。使用较早版本、还没有修复面板时，也可以按下面的方法手动处理。开始前连接原来的外置盘，完全退出要修复的应用，并保留现有数据和备份。
开机自动重签名
当前开发版会在 macOS 27 及以上停用「开机自动重签名」，停止并移除旧登录任务；关闭未完成时，可在设置页重试。
升级系统前，请先更新并打开一次 AppPorts，让已安装的后台任务获得版本保护。只下载新版、尚未打开时，旧后台任务不会自动更新。
第 1 步：还原旧方式迁移的容器数据
修复面板会检查容器目录。存在指向外置盘的旧符号链接时，点「全部还原」；没有此类目录时，跳过这一步。手动操作路径是「数据目录」→「应用数据」→ 选择应用 → 还原状态为「已链接」的容器目录。
恢复原始应用后，沙盒限制也会恢复，因此要先处理旧符号链接，否则应用可能读不到原来的数据。已经使用 APFS 挂载迁移的目录不需要为了签名修复而还原。
第 2 步：恢复原始签名，或从官方渠道重装
按备份情况选择一种方式：
- 有完整原始应用备份： 点「恢复原始签名」，按提示恢复原始应用及其签名。AppPorts 会定位真实应用，应用本体在外置盘时也可恢复，不必先搬回本机。AppPorts 会校验当前应用与备份是否匹配；当前应用已更新或内容不匹配时，会要求提供匹配的官方原版。
- 只有旧的签名记录： 可选择同版本的官方原版
.app补救，或从 App Store / 开发者官网下载重装。仅有证书名称的记录不能重建开发者签名。 - 准备覆盖安装，且应用本体在外置盘： 先点「迁回本地」，再安装官方版本，避免只覆盖本地启动入口而留下外置副本。
不要卸载或清理容器数据目录。 这里要恢复的是应用本体和签名。聊天记录、登录状态是否能继续使用，还取决于数据本身、应用版本和原有授权；重要数据应另有备份。详见签名备份与恢复。
第 3 步：重新检查，并从 Finder / Dock 打开
回到修复面板点「重新检查」，确认签名检查通过，再从 Finder 或 Dock 打开应用，检查原有数据是否能访问。终端里能启动不能替代这一步。
「暂时无法检查签名」表示这次检查没有得出结果，应连接外置盘后重试，不能算作「签名已替换」或「已经修好」。普通扫描不会删除恢复备份。
如果应用目前仍能打开，可以稍后处理；这不等于原始签名已经恢复。准备继续迁移容器数据时，应先完成修复。
第 4 步（可选）：继续把数据放到外置盘
修复后，到「应用数据」页选择要迁移的目录，点「迁移」。AppPorts 会先检查目标存储，容器数据使用 APFS 挂载迁移，不需要重签名。
当前方案需要未加密的 APFS 外置盘。目标不合适时，可以更换存储，也可以让数据继续留在本机。第一次打开应用时，如果 macOS 询问是否允许访问可移动宗卷，点「允许」。以后使用应用前，先连接外置盘。准备方法见为什么外置盘必须是 APFS。
谁会受影响
| 情况 | 如何判断 |
|---|---|
| 签名可能被替换 | AppPorts 留有原始开发者签名的备份记录，且真实应用当前明确为 Ad-hoc 签名 |
| macOS 27 兼容性风险 | 曾对沙盒应用重签名，尤其是迁移过 ~/Library/Containers/ 或 ~/Library/Group Containers/ 数据的应用 |
| 典型表现 | 从 Finder / Dock 打开时无反应，或图标一闪即退出 |
| 现有测试记录 | 微信 4.1.15、macOS 27.0 (26A428) 出现过此问题；同机的 QQ 音乐仍可打开，不能推断所有应用都会失败 |
| 无法检查 | 外置盘未连接、读取失败或检查超时；应重试，不应直接判定签名损坏 |
仅有 Ad-hoc 签名不代表应用被 AppPorts 改坏：有些应用本来就采用这种签名。也不能因为应用已迁移、位于容器目录或尚未能检查签名，就提示用户重新签名。
重签名可能移除原有沙盒身份和授权。macOS 27 核对容器访问资格时，已有的签名授权记录可能不再匹配。微信的相关日志包含 Failed to match existing code requirement。原理和测试限制见容器数据、沙盒与签名身份。
不要做的事
| 做法 | 原因 |
|---|---|
| 只还原数据，就认为修复完成 | 数据路径和应用签名是两个检查项，恢复路径不会恢复开发者签名 |
| 再点一次「重签名」 | 不能找回原有开发者签名，还可能再次移除授权 |
| 删除容器目录后重装 | 容器里可能保存聊天记录和设置，签名修复不需要删除这些数据 |
| 只用终端启动判断是否修好 | 应验证 Finder / Dock 启动和应用内数据访问 |
还没升级：先检查
优先在 AppPorts 中查看「签名已替换」标记，并按上面的修复处理。没有标记不等于已经验证 macOS 27 兼容性；AppPorts 只能根据可读的真实应用和已有备份判断签名是否被替换。
进阶：用终端辅助检查旧备份
下面的只读脚本只检查备份记录中仍可访问的应用路径。应用已移动、外置盘未连接或本地路径变成启动入口时，可能漏报；它不是完整兼容性检测。
BACKUP_DIR="$HOME/Library/Application Support/AppPorts/signature-backups"
for plist in "$BACKUP_DIR"/*.plist; do
[ -f "$plist" ] || continue
original=$(/usr/libexec/PlistBuddy -c "Print :signingIdentity" "$plist" 2>/dev/null)
app=$(/usr/libexec/PlistBuddy -c "Print :originalPath" "$plist" 2>/dev/null)
case "$original" in ""|ad-hoc) continue ;; esac
[ -d "$app" ] || continue
if codesign -dv "$app" 2>&1 | grep -q "Signature=adhoc"; then
printf "%s\n 原始签名: %s\n" "$app" "$original"
fi
done已升级：确认症状
先从 Finder / Dock 打开应用。若失败且 AppPorts 显示「签名已替换」，按修复处理。若签名检查正常，仍无法启动，应进一步排查应用版本、数据权限和外置盘连接。
进阶：查看签名和系统日志
把示例路径替换为真实应用的路径；迁移后本地的启动入口不代表外置应用的签名。下面的命令只读取信息。
codesign -dv --verbose=4 "/Applications/WeChat.app" 2>&1 | grep -E "Authority|TeamIdentifier|Signature"
log show --last 1m --style compact 2>/dev/null | grep -i "rejected approval request"Signature=adhoc 需要与原始签名记录一起判断。kTCCServiceSystemPolicyAppData ... denied 是容器访问被拒绝的线索，单独出现不能证明一定由重签名导致。更多检查见容器数据、沙盒与签名身份。
AppPorts 1.9.0 做了什么
以下是当前开发版本的处理方式：
- 默认模式下，容器数据使用挂载迁移，不依赖移除沙盒或替换签名。
- 默认模式拒绝对沙盒应用重签名；经典数据迁移模式保留旧行为，默认关闭。
- 「恢复原始签名」使用完整原始应用备份；旧记录可选择同版本官方原版补救。
- 已确认的签名替换和无法完成的检查分别显示，保留检查与恢复入口。
- 旧容器符号链接仍可还原。更新 AppPorts 不会自动恢复曾被替换的签名。
常见疑问
聊天记录会不会丢？
签名错误本身不代表聊天记录损坏。保留容器目录、外置盘数据和备份，不要使用会清理应用数据的卸载工具。恢复后仍需打开应用验证；登录状态等授权可能需要重新建立。
我还原了数据还是打不开？
还原数据只解决路径问题。继续检查签名；有完整备份时恢复原始应用，否则从官方渠道重装。签名正常后仍无法打开，再检查应用版本与系统权限。
只有微信会这样吗？
不一定。已有测试观察到不同应用表现不同，因此提示的是需要检查的风险，不是每个应用都会失败的结论。
是 AppPorts 把数据弄坏了吗？
已观察到的启动故障与旧方式重签名有关，不是数据损坏的证据。是否存在其他数据问题，需要保留原件并单独检查。默认的 APFS 容器迁移不会替换应用签名。