下午发现 Chrome 上感觉有 5 个内容在下载,但下载管理器里看不到具体文件。
顺手检查了系统状态,还把手边一块外置 SSD 格式化了。
到这个
先看 Chrome 的情况,其实挺常见的——你看到“有东西在下”,但点开下载列表啥也没有。
活跃的下载:
- 在
~/Downloads/里发现了两个隐藏文件:.com.google.Chrome.6DxAt9(约 122MB)和.com.google.Chrome.tDaQRj(约 70MB) - 这些名字以
.com.google.Chrome.开头的,是 Chrome 下载时临时生成的文件 - 其中一个被 Chrome 主进程(PID 72440)锁着,而且文件大小还在涨
下载历史:
- 查了 Chrome 的数据库,发现有 6 个中断的下载(state=2)
- 加上现在正在下的那个,正好对应你感觉到的“5 个”
为啥看不到?
因为 Chrome 只会把真正完成、有最终文件名的下载显示出来。
如果中途断了,或者还没重命名成最终名字,它就不显示。
这些中断记录还在数据库里挂着,就容易让人误以为还在下。
回到正题
顺便看了眼系统整体状态,没毛病:
- CPU 负载正常
- 内存用了大概 60%
- 磁盘空间很充足
- Chrome 进程数量也合理(主进程 + 多个渲染器 + helper)
- 网络主要是本地代理和常用服务,没啥异常流量
第一个坑
然后顺手处理了一下手边那块 Lexar ES3 外置 SSD(1TB),之前是 ExFAT + MBR 分区:
| 项目 | 之前状态 |
|---|---|
| 容量 | 1.0 TB |
| 格式 | ExFAT |
| 分区方案 | MBR |
| 已用空间 | 仅 63MB |
ExFAT 虽然 Mac 能读写,但有个大问题:不支持 Time Machine 备份、APFS 快照和加密功能,大文件稳定性也不如 APFS。
决定改造成 APFS + GUID 分区方案,更适合 Mac 生态:
# 先卸载
diskutil unmountDisk /dev/disk4
# 格式化为 APFS,GUID 分区
diskutil eraseDisk APFS "jf01" GPT /dev/disk4
格式化完效果不错:
| 项目 | 新状态 |
|---|---|
| 格式 | APFS |
| 分区方案 | GUID (GPT) |
| 可用容量 | 954 Gi |
| 用途 | Time Machine 备份 + 日常存储 |
APFS 是苹果原生优化的文件系统,对 SSD 性能最友好,还能用快照、空间共享、自动恢复损坏文件,真香。
最后一句
Chrome 那几个“看不见”的下载,其实是旧账没清理干净;
系统本身没问题;
SSD 从 ExFAT 升级到 APFS 后,不仅更稳定,还能直接给 Time Machine 用——这才是真正的一步到位。