苹果 macOS Bug 报告未经修复即关闭

# Apple 未经验证修复就关闭 macOS 错误报告

开发者 Jeff Johnson 揭露了 Apple 正式关闭 macOS 错误报告却并未实际修复问题的做法。该公司要求报告者验证测试版中的缺陷，无视任何无回应情况，并将工单标记为“已解决”。

网络数据泄漏案例

2023 年 3 月，Johnson 提交了报告 FB12088655，内容涉及 IP 地址和 TCP 连接通过 macOS 网络过滤器泄漏。该报告包含：

• 详细的重现步骤。
• 一个测试 Xcode 项目。
• 问题的公开描述。

Apple 接受了该报告，但近三年未作回应。2026 年 3 月，支持团队要求他检查 macOS 26.4 beta 4。Johnson 拒绝测试测试版，称不想充当免费的 QA 工程师。

支持团队未说明修复是否包含在 beta 4 中，并给了他两周时间回应。没有确认，工单将被关闭为已解决。Johnson 在 macOS 26.4 正式版上的测试确认了该 bug 依然存在，但 Apple 并未让内部测试员验证。

报告处理中的系统性问题

Johnson 描述了一个反复出现的模式：

• 提交带有完整重现步骤的报告。
• Apple 忽略数月或数年。
• 要求在测试版中重新确认。
• 如果无回复，则不作回应就关闭。

最近例子：一个 100% 可重现的 bug 被以“诊断失败”状态关闭。重新打开后两周内无支持回应。

开发者怀疑 Apple 的成功指标中，开放工单数量会影响团队 KPI。这激励无论是否修复都关闭报告。

对 macOS 开发者的影响

此政策打击了外部贡献者的积极性。中高级开发者花费时间撰写详细报告，却面临被忽略或无休止的重新确认循环。

• 安全风险： 如 FB12088655 这样的泄漏未修复，威胁用户隐私。
• 操作系统质量： 不一致的处理方式侵蚀了对平台的信任。
• 替代方案： Johnson 推荐使用公开帖子而非 Feedback Assistant。

Apple 的内部 QA 本可以自行处理重现步骤，但实际情况并非如此。

关键要点

• Apple 在未确认修复的情况下关闭 macOS 错误报告，要求报告者在测试版中重新确认。
• 示例：三年前的报告 FB12088655 涉及网络过滤器中的 IP/TCP 泄漏，在 macOS 26.4 中仍未解决。
• 政策提升指标：关闭工单 = 成功，无论质量如何。
• 开发者浪费时间充当免费测试员。
• 建议：公开细节以施压公司。

— Editorial Team