用一些 JavaScript 清理我的 200GB iCloud
Apple 的 iCloud Photo Library 被指报告了夸大的存储占用：一些用户发现，视频在 iCloud 中被计算得远大于他们实际能够下载到的文件。评论者提出了技术上的解释——例如隐藏的原件、编辑历史、多种编码以及不透明的 Photos 库元数据——但认为 Apple 的工具让人很难看清或清理到底是什么在占空间，从而把用户推向更高价的存储档位。也有人分享了变通办法、第三方工具和自托管方案，同时指出更广泛的担忧，包括锁定效应、糟糕的数据导出，以及订阅驱动的产品选择。
iCloud 存储差异
- 一些评论者认为，所报告大小与实际文件大小之间的不匹配可能很严重，如果普遍存在，甚至可能值得提起诉讼。
- 另一些人认为，这主要就是 Photos 和 iCloud 的工作方式：原始文件始终会保留，编辑只是元数据，而额外的应用专属数据（缩略图、人脸数据、版本）会被存储并同步。
- 一些技术猜测包括：视频的多种编码或分辨率、HEIC 多帧容器、备份/版本控制，以及内部对象存储开销。
- 文中一个例子（报告为 128 MB，实际文件 48 MB，删除后释放约 170 MB）让人怀疑存在隐藏的额外副本或格式。
- 共识是：这种行为在技术上也许说得通，但它是黑箱式的，而且在按付费额度计费时会让人感觉很不友好。
不透明和糟糕的工具
- 许多人抱怨 Apple 的界面不显示每个项目的真实大小，也不让清理变得容易，尤其是在 Photos、iMessage 和 iCloud 备份方面。
- iCloud 中的 iMessage 被特别点名：没有网页视图、搜索失效、大小报告不准确、删除过程缓慢且有 bug，并且可能存在数据库损坏。
- 有些人认为这是一种“黑暗模式”设计，目的是把用户推向更高、且按月/按年持续收费的存储档位。
定价和档位
- 常见的不满包括：
- 5 GB 免费额度对现代设备来说几乎没用。
- 50/200 GB 与 2 TB 之间跳跃太大，却没有 400–500 GB 这样的“中间”档位。
- 也有人反驳说，云存储很便宜，与其自己管理多设备备份，不如付费更划算。
变通办法和工具
- 用户提到：
- 通过 Windows 版 iCloud 应用、在关闭“优化储存”的 Mac Photos 中，或使用 Apple 的数据导出门户下载所有媒体。
- 第三方工具：iCloud 照片下载器、osxphotos（包括在保留元数据的同时清理 RAW+JPEG）、PhotoSync、去重应用，以及利用 PhotoKit 或 AppleScript 的脚本。
- 一个基于文章中的 JS 片段改写的 Tampermonkey/Greasemonkey 脚本，用于在 iCloud Photos 网页界面中高亮大文件。
自托管和替代方案
- 一些人更喜欢自托管照片方案（例如 NAS + Immich 之类的应用），因为它们更透明、可控，同时也承认这会更复杂，而且仍然需要单独备份。
- 也有人明确选择大型云服务商（Apple、Google、Microsoft），尽管有这些问题，但还是图方便。
未解问题
- 目前仍不清楚，这种差异有多少是 bug，有多少是有意设计。
- 也不清楚在所有情况下，共享相簿、实况照片以及内部衍生文件到底有多少会计入 iCloud 配额。