mac电脑的奇怪问题

交换内存

遇到系统卡顿, 电脑发热, 很大可能是系统疯狂读写swap内存

检查 Swap 与物理内存状态

# 查看 Swap 使用量 和 内存压缩/物理内存情况
sysctl vm.swapusage && top -l 1 | grep -E "^PhysMem|^VM"

输出示例解析： 重点关注swap和compressor

vm.swapusage: total = 18432.00M  used = 16904.25M  free = 1527.75M  (encrypted)
PhysMem: 31G used (3493M wired, 14G compressor), 76M unused.
VM: 329T vsize, 5684M framework vsize, 33786912(0) swapins, 39293032(0) swapouts.

used = 16904.25M (Swap): 极度危险！说明物理内存已经彻底打满，有 16.9G 的数据被迫写到了硬盘上。
76M unused: 物理内存几乎完全枯竭（32G 内存仅剩 76M）。
14G compressor: macOS 的特色机制。在动用 Swap 前，系统会拼命压缩内存数据。当压缩占用高达 14G 时，说明系统已经在超负荷运算来维持不崩溃了。
swapins / swapouts (几千万次): 系统在内存和硬盘间疯狂搬运数据（Thrashing），这是导致卡顿的直接元凶。

确认了系统处于高压状态后，需要找出是谁吃掉了内存。

按 RSS (常驻物理内存) 排序抓取前十

ps -amcwwwxo "user,pid,rss,vsz,command" -r | head -n 15

参数解释：-r 按 CPU 占用排序（在某些 macOS 版本中需结合 RSS 字段观察），但更直观的是提取出前十名直接看 RSS 列。

输出示例解析：

USER               PID    RSS      VSZ COMMAND
wenliu            3689 4681920 417675024 mongod
wenliu           47121 3013056 1867840992 Google Chrome Helper (Renderer)
wenliu             649 235536 414167584 Terminal
wenliu           94155 216688 446452352 node

RSS (Resident Set Size): 进程实际占用的物理内存（单位：KB）。
- 例如 mongod 的 RSS 是 4681920 KB（约 4.6 GB），它就是当前最大的刺客。
- Google Chrome Helper 占用约 3 GB，通常是某个臃肿的网页或插件。
VSZ (Virtual Memory Size): 虚拟内存。通常很大（有些进程申请 1.8G+），不需要过度恐慌，重点看 RSS。

典型嫌疑人与处理方案

在实际排查中的三种典型的压力源转移：

嫌疑人 A：Google Chrome (及各种 Electron 应用)

特征：产生大量 Helper (Renderer) 进程。
处理：使用 Chrome 自带的任务管理器 (Shift + Esc) 揪出具体标签页并关闭，或者直接彻底重启浏览器。

嫌疑人 B：数据库服务 (如 MongoDB)

特征：当你运行了重度查询（如量化历史回测）后，mongod 会将大量数据加载到内存中作为缓存，且不会轻易释放。
处理：如果是本地开发环境，最快的方法是直接重启服务释放内存：
```
brew services restart mongodb-community
```

嫌疑人 C：Node.js (本地 Agent/构建工具)

特征：node 进程带着 --max-old-space-size=16384 这样的参数。
处理：确认该进程（如 gemini 助手或 Webpack 构建）是否正在工作。如果是正常工作，几百兆的占用是合理的；如果是僵尸进程，直接 kill -9 <PID>。

4. 关键认知：Swap 的滞后性

系统被迫使用大量swap后, 即使解决了关键问题, 系统也未必能恢复:

即使杀掉大进程, 物理内存（RAM）被释放, 但 swap 会维持原状，直到需要访问里面的数据, 仍然会感到“冷启动”的卡顿
压缩本身会给CPU 的内存管理单元（MMU）造成很大压力, 系统会不停压缩解压缩, 影响响应
物理内存很难优化排布, 变得碎片化, 频繁触发整理

到这个时候就不得不重启电脑让内存重新恢复了如何判断“不用重启”？你可以通过一个指标来反驳“高 Swap 就重启”的说法：swapins / swapouts 的变化率。

运行 vm_stat 1（每秒刷新一次）：

如果 Swap Used = 10GB，但 swapins 和 swapouts 都是 0，说明这些 Swap 是“静止的冷数据”，你不动它，它就不占性能。这时不需要重启。
如果 Swap Used = 10GB，且当你切换程序时，swapins 开始狂跳，说明系统正在疯狂从硬盘搬运数据，这时候重启才是解药。

声音

coreaudio

网络

诊断与连通性检查

ping -c 2 114.114.114.114 #物理联网
nslookup baidu.com 114.114.114.114  #DNS 穿透状态
nslookup baidu.com #本地代理劫持情况

输出示例解析：

Address: 110.242.xx.xx: 正常真实 IP。说明基础链路和 DNS 53 端口没问题。
Address: 198.18.x.x (Fake IP): 说明流量正被代理软件（Clash/Surge）接管。
connection timed out: 严重故障。说明运营商解析服务掉线或 53 端口被拦截。

典型故障与处理方案

故障 A：DNS 链路失效 (典型“微信通网页不通”)

特征：ping 通，但 nslookup (不带服务器) 失败；或者解析出的 IP 无法访问。
处理：
- 多个软件抢dns导致混乱(tailscale, clash等): scutil --dns (查看解析器顺序)
  - tailscale设置 tailscale up --accept-dns=false --accept-routes=false --exit-node=
    - 不去抢系统或代理软件的dns解析
    - 不默认添加来自 Tailscale 网络中其他机器分享的“局域网段”: 如果你当前所在的酒店/咖啡厅 Wi-Fi 恰好也是 192.168.1.x 段，就会发生 “路由冲突”。你会发现连不上酒店打印机，甚至连不上网，因为Mac以为那是你家的网络，把包发到了隧道里
    - 清空出口节点: 防止网络流量被tailscale截胡
  - clash设置: 在 DNS 字段添加 nameserver-policy: {"*.ts.net": 100.100.100.100}
    - 修改clash的配置文件

故障 C：系统配置损坏 (Wi-Fi 开关异常/搜不到信号)

特征：UI 层面 Wi-Fi 无法开启，或者即便连接也无法获取 IP。
处理：由浅入深进行重置。
- 重置接口：在网络设置中删除 Wi-Fi 接口 -> 应用 -> 重新添加 -> 应用。
- 清理文件：删除 /Library/Preferences/SystemConfiguration/ 下的 NetworkInterfaces.plist 和 preferences.plist 后重启。
- 底层重置 (NVRAM)：关机后长按 Option+Command+P+R 开机，听到 3 声响后松开。