storage-analyzer

Storage Analyzer

源自 KKKKhazix/khazix-skills（MIT，见 LICENSE）， 本仓库在其基线上增加了 Linux 支持并加固了安全模型 —— 详见 UPSTREAM.md。

对 macOS / Windows / Linux 做一次只读存储分析，产出交互式 HTML 报告。流程：扫描 → 分析分级 → 生成网页 → 打开。

铁律

• 全程只读。 只能跑扫描/统计/列目录/读元信息（df、du、diskutil、stat、ls）。绝对禁止 rm、mv、rmdir、清空回收站、改权限等任何写操作。
• 删除命令只展示，不执行。 报告里给出的清理命令是供用户自己在终端确认后运行的。即使用户在对话里说"帮我删"，也要先停下确认（命中全局红线：删除文件必须先问），不要直接代跑。
• 估算标注清楚。 涉及"可释放空间"一律说明是估算值。
• 路径、命令保留原文不翻译。

执行流程

Step 1 扫描（只读）

python3 scripts/scan.py > /tmp/storage_scan.json

scan.py 自动识别系统（sys.platform）：

• macOS：扫 home、library、caches、containers、group_containers、app_support、applications、downloads、dev_caches，用 du 算大小。
• Windows：扫 user_profile、appdata_local、appdata_roaming、temp、downloads、program_files(_x86)、dev_caches，用 os.scandir 算大小；system.disks 含所有盘符。
• Linux：扫 home、cache、local_share、config、downloads、flatpak_apps、snap_home、opt、usr_local、dev_caches，用 du -x 算大小（-x 不跨挂载点，否则外置盘会被算进主盘）。另有两组 Linux 专有：sudo_targets（/var/lib/docker、/var/log 等 root 大户，读不到就标 denied）和 uncategorized（$HOME 与 /var 各一层兜底下钻，捞出目标表没覆盖到的大目录）。system.disks 含所有本地挂载点（已滤掉 tmpfs / squashfs / 网络盘）。

输出 JSON：system（系统/磁盘信息，含 disk_name 主盘名 + disks 全部盘）+ groups（各组子目录大小，已降序、过滤 50MB 以下）。扫描较慢，耐心等。读不到的目录标 denied，需在报告里列出并提示遗漏体量。

Linux 另有 accounting 字段（缺口对账），必须读：Linux 上 du 对 root 目录是静默低估（读不到算作 0 还返回成功），不对账就会把大户报错。对账按文件系统分别进行（per_filesystem 数组），因为 /home 独立分区极常见，合并算会捏造出巨额假重叠。每项的 gap_kb 归入该盘蓝色「系统及其他」并提示可用 sudo 核实；若出现 overlap_kb（合计超过实际已用），说明有硬链接缓存被重复计数（也可能是压缩/reflink/稀疏文件），相关项的"可释放空间"要注明实际释放量可能更小。条目上的 partial: true 表示 du 没读全、实际更大；mountpoint: true 表示该子目录是另一块盘的挂载点，不计入本盘。

Step 2 分析与分级

先看 system.os 判断系统，读对应的数据布局参考：macOS 读 references/macos.md，Windows 读 references/windows.md，Linux 读 references/linux.md（讲该系统东西存哪、怎么辨认、归哪一级）。然后读 /tmp/storage_scan.json 做这几件事：

1. 挑 Top 5 占用大户，判定类型（系统资产/应用本体/应用数据/应用缓存/开发缓存/用户文件/媒体内容/下载内容/虚拟机镜像/回收站/其他）。
2. 识别"神秘大目录"：UUID 命名的 Container、不明的隐藏目录，要追查它属于哪个 App、装的是什么（例如某 97GB 的 UUID Container 实为 Bilibili 离线视频缓存）。必要时 ls/du 深入一层看清楚，但仍只读。
3. 三级分类 = 清理决策清单，不是全盘点。 只把"存在'要不要动它'这个决策"的项放进三灯；日常在用的正常应用、操作系统本身、海量零碎小文件没有清理决策，不进三灯，它们落在磁盘条的蓝色"系统及其他"里。判定标准：
   • 🟢 可自动清理：纯缓存、临时文件、安装包残留、明确可再生且不影响功能、不丢用户数据（pip/uv/npm/Xcode DerivedData 等开发缓存、浏览器缓存）。
   • 🟡 需人工判断：含用户数据或有判断成本（离线视频、文档、项目代码 node_modules、聊天记录、设计稿）。给内容画像 + 至少 3 句处置路径（应用内清理 / 系统工具 / 文件管理器手动审查，三选最合适）+ 风险提示。所有橙灯项在服务模式下自动有「在访达/资源管理器打开」按钮（跳过去自己审查删）；如果该项有一个核实过、删了不破坏 App 的安全子路径（如 B站离线视频的 .Downloads 目录、旧备份目录），给它 trash_paths → 网页出现「移到废纸篓」按钮（橙灯只准移废纸篓、可逆，绝不给"直接删除"）。App 托管又无安全子路径的（Chrome/微信）只给打开按钮、不给 trash_paths。按钮下方会自动写明注意事项（打开只查看不删、移废纸篓可逆需清空才释放等）；如果某项在文件管理器里是 App 内部格式、不方便手动挑选，给它一个 open_note 字段做客观说明（会显示在注意事项里）。口吻要中性、像产品说明：直接描述"这里是什么结构、为什么不好手动删、想精细操作该去哪"，不要写成"我发现/提醒注意/看着像没视频"这种暴露开发者踩坑视角的话。
   • 🔴 谨慎清理（有决策但不建议手删）：你可能想动、但建议别手删的具体项——重复安装的应用、想卸载的大应用、运行中应用的核心数据等。给"为什么不建议手删" + indirect_release 写具体卸载步骤（自带卸载器 / 启动台长按 / 右键移废纸篓 / AppCleaner 清残留 / App Store 可重装等，要可照做不是空话）。应用项给 app_paths（真实 .app 绝对路径数组）→ 网页出现「在文件管理器打开（去卸载）」按钮，定位到 App 让用户自己正规卸载。红灯不给删除/卸载按钮（应用在系统目录、可能要管理员密码、可能有自带卸载器和残留，后台代删不稳妥）。纯系统文件、APFS 快照不要单独列红卡（没有清理决策），归蓝色即可；系统层面的释放技巧（重启释 swap、Time Machine 快照策略、可清除空间自动回收）写进 summary.long_term 长期建议。