文章摘要
文章揭露苹果公司随意关闭用户提交的Bug报告，除非用户验证问题仍存在。作者批评苹果不尊重用户的时间和反馈，认为公司对待Bug报告的态度傲慢，仿佛用户有义务为苹果服务。尽管作者曾尝试组织抵制活动，但效果不佳。
文章总结
苹果公司随意关闭漏洞报告，除非用户"验证"漏洞仍存在
开发者Jeff Johnson近日发文批评苹果公司处理漏洞报告的糟糕方式。他指出，苹果在收到漏洞报告后长期不予回应，却在三年后突然要求他验证漏洞是否在macOS 26.4测试版中仍然存在，并威胁若两周内不验证就将关闭报告。
Johnson在2023年3月提交了编号FB12088655的漏洞报告，涉及网络过滤扩展的TCP连接和IP地址泄露问题。三年来苹果从未回应，直到最近才要求他验证该问题是否在测试版中修复。由于不愿全年充当无偿测试员，Johnson并未安装测试版系统，但通过与Little Snitch开发团队沟通确认该漏洞在macOS 26.4测试版4中仍然存在。
更令人不满的是，苹果近期还将另一个100%可复现的漏洞（FB22057274）标记为"调查完成-当前信息无法诊断"，却从未说明需要哪些额外信息。Johnson认为，苹果内部可能存在通过人为减少未解决漏洞数量来掩盖软件质量问题的机制。
讽刺的是，iPadOS 26.4测试版中出现的Safari崩溃漏洞虽已被报告一个月，苹果却未能在正式版发布前修复。Johnson质疑测试版的实际作用似乎只是给提交漏洞的用户制造麻烦。
[注：原文中的个人链接、时间标记等非核心内容已作删减处理]
评论总结
总结：
对苹果处理方式的批评（主要观点）
- 认为苹果通过"验证"机制拖延处理，实际是变相关闭问题
- 关键引用："每个Radar都必须经过验证状态...导致数千Radar滞留验证状态"(评论7)
- 关键引用："苹果几十年来都忽视bug报告"(评论16)
开发者角度的辩解（次要观点）
- 解释难以复现的bug确实需要用户验证
- 关键引用："不是所有bug都容易复现...保持未修复状态可能更糟"(评论5)
- 关键引用："难道要停止所有更新直到复现每个模糊bug？"(评论3)
行业普遍现象（中立观点）
- 指出类似做法在科技公司普遍存在
- 关键引用："这是企业软件的经典套路"(评论8)
- 关键引用："Facebook/Google都有类似规避bug的技巧"(评论15)
用户挫败感（情感表达）
- 用户报告高质量bug却得不到解决
- 关键引用："最挫败的是那些认真提交高质量问题的用户"(评论13)
- 关键引用："我已停止提交bug报告...要付出巨大努力证明bug存在"(评论14)
正面案例（对比参考）
- 提到Chromium团队处理bug的高效
- 关键引用："Chromium团队通常几天内就能复现并修复"(评论10)
系统性问题（深层分析）
- 指出问题根源在于组织考核机制
- 关键引用："源于愚蠢的组织级指标和SLA政策"(评论15)
- 关键引用："团队因'组织健康'报告压力而关闭旧问题"(评论7)
注：评论中存在部分情绪化表达（如评论17/18）未纳入总结，但保留了相关观点的理性表达部分。总结涵盖了主要观点分布，保持正反方平衡，同时反映高认可度评论（如获大量支持的评论7/15）。