DeepSeek Sidebar 现在已经发布到 Chrome 应用商店:
如果你经常一边浏览网页、一边向 AI 提问、总结内容、改写文案或整理资料,那么在不同标签页之间来回切换会很打断思路。DeepSeek Sidebar 的目标很简单:把常用 AI 聊天工具放进 Chrome 侧边栏,让它始终停在你正在浏览的网页旁边。
Continue reading DeepSeek Sidebar 已上架 Chrome 应用商店:把 AI 助手放进浏览器侧边栏
DeepSeek Sidebar 现在已经发布到 Chrome 应用商店:
如果你经常一边浏览网页、一边向 AI 提问、总结内容、改写文案或整理资料,那么在不同标签页之间来回切换会很打断思路。DeepSeek Sidebar 的目标很简单:把常用 AI 聊天工具放进 Chrome 侧边栏,让它始终停在你正在浏览的网页旁边。
Continue reading DeepSeek Sidebar 已上架 Chrome 应用商店:把 AI 助手放进浏览器侧边栏
我做了一个很小、很直接的 Chrome 扩展:Octoman Read Later。
它的用途只有一个:当你看到一篇文章、一个教程、一份文档,暂时没时间看时,可以一键把当前页面保存到稍后阅读列表里,然后安心关掉标签页。
安装地址:

你有没有遇到过这样的场景——精心准备了一篇公众号文章,上传封面图时系统提示「文件大小超过 5MB」?或者公司网站的首页 Banner 加载了整整 8 秒,打开 DevTools 一看,一张 12MB 的 hero 图赫然在列?
图片,是网页体积的大头。根据 HTTP Archive 的统计,一个典型网页平均有 60% 以上的流量花在图片上。而大部分图片,压缩后肉眼看不出任何区别,体积却能砍掉 50% 到 80%。
Nacos 2.5.2 在 macOS M1 上的内存下限实测:500MB 降不动
Nacos 2.5.2 standalone 模式默认只设了堆 -Xms64m -Xmx128m,Metaspace 和 DirectMemory 完全没上限,实际 RSS 在 500MB 左右。想压更低,试了一圈,结论是:500MB 基本是硬下限。
踩过的坑
试过把堆降到 96m,运行 70 秒后 OOM 退出,没有 heapdump,静默挂掉。试过把线程栈压到 192k,JDK 11 在 macOS arm64 上直接拒绝启动——最低 208k。试过 Metaspace 上限设 128m,启动到 Derby 加载阶段就挂,因为 Nacos 光启动就要 140-150MB 的类元数据。
用 NMT 拆解 RSS 构成
开启 -XX:NativeMemoryTracking=summary 后用 jcmd VM.native_memory summary 逐项看,500MB 的去向很清楚:
| 区域 | 占用 | 说明 |
|---|---|---|
| Metaspace | 93MB | 16351 个类,Nacos 体积决定的硬需求 |
| Java Heap | 123MB | Xmx 128m 几乎满,96m 运行时不够 |
| 线程栈 | 67MB | 227 个线程,macOS 强制 208k/线程下限 |
| Symbol 表 | 19MB | 类加载的副产品,不可调 |
| Code Cache | 28MB | JIT 编译代码 |
| Direct Memory | ~70MB | gRPC/Netty 堆外内存 |
| JVM 自身 + 共享库 | ~50MB |
几乎全是 native 内存,JVM 参数设上限只能防止失控,降不了实际占用。
最终配置
startup.sh 第 95 行 standalone 分支改为:
JAVA_OPT="${JAVA_OPT} ${CUSTOM_NACOS_MEMORY:- -Xms64m -Xmx128m -Xmn32m -XX:MetaspaceSize=64m -XX:MaxMetaspaceSize=192m -XX:MaxDirectMemorySize=96m -XX:+UseSerialGC -Xss256k -XX:ReservedCodeCacheSize=64m}"
每一项的作用:-XX:+UseSerialGC 替掉 G1GC 省 GC 元数据;-Xss256k 从默认 1m 砍到 1/4;MaxMetaspaceSize=192m 和 MaxDirectMemorySize=96m 封顶防失控;ReservedCodeCacheSize=64m 从默认 240m 降到 64m。
实测 RSS 仍在 500MB 左右,但这套参数封住了所有可膨胀的 native 内存区域,长期运行不会因为 Metaspace 或 DirectMemory 无上限而持续增长。
还想往下压的三条路(超出 JVM 调参范畴)
startup.sh -m standalone -f naming 只跑服务发现,跳过配置中心,实测 RSS 降到 485MB,省 50MB,代价是 config 不可用。底线:Nacos 这种 Spring Boot 重应用,光 JVM 自身结构 + 类元数据 + gRPC 堆外就要 400MB+,这是物理约束。想突破 500MB 得从减少加载模块入手,不是调参能解决的。
1. 备份原文件
cp nacos/bin/startup.sh nacos/bin/startup.sh.bak
2. 改 standalone 分支
编辑 nacos/bin/startup.sh,找到第 95 行(standalone 分支):
# 原始(只有堆)
JAVA_OPT="${JAVA_OPT} ${CUSTOM_NACOS_MEMORY:- -Xms64m -Xmx128m -Xmn32m}"
# 改为
JAVA_OPT="${JAVA_OPT} ${CUSTOM_NACOS_MEMORY:- -Xms64m -Xmx128m -Xmn32m -XX:MetaspaceSize=64m -XX:MaxMetaspaceSize=192m -XX:MaxDirectMemorySize=96m -XX:+UseSerialGC -Xss256k -XX:ReservedCodeCacheSize=64m}"
只改 standalone 那行,集群分支(第 101 行)不动。
3. 重启验证
sh nacos/bin/shutdown.sh
sh nacos/bin/startup.sh -m standalone
# 等 1 分钟,确认 HTTP 200
curl -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8848/nacos/
4. 如果另一台不是 M1 而是 Intel Mac
参数完全一样,但线程栈下限不同,Intel 上 -Xss256k 可以更低。如果还想压,试 -Xss208k,不过省不了多少。
5. 如果另一台是 Linux/Windows
-Xss256k 可能可以降到更激进(某些 Linux 平台最低 160k),但也省不了几 MB,不值得折腾稳定性。
macOS chronod 占用 100% CPU 的排查与修复
现象:活动监视器中 chronod 长时间占用 100% 以上 CPU,重启系统后仍然存在。
进程路径:
/System/Library/PrivateFrameworks/ChronoCore.framework/Support/chronod
chronod 主要和 macOS 小组件、通知中心、App Intents、时间线数据同步有关。日志中如果反复出现这些关键词,通常说明它卡在小组件同步或缓存处理上:
com.apple.chrono
NotificationCenter
ReplicatorServices
remoteArchives
widget-relevance-cache
可先尝试关闭 iPhone 小组件:
系统设置 -> 桌面与程序坞 -> 小组件 -> 使用 iPhone 小组件
然后重启相关进程:
killall chronod 2>/dev/null
killall NotificationCenter 2>/dev/null
如果仍然高占用,清理 chronod 缓存和数据库,让系统自动重建:
mkdir -p ~/Desktop/chronod-backup
killall chronod 2>/dev/null
killall NotificationCenter 2>/dev/null
mv "$HOME/Library/Caches/com.apple.chrono" \
"$HOME/Desktop/chronod-backup/com.apple.chrono-$(date +%Y%m%d-%H%M%S)"
mv "$HOME/Library/Group Containers/group.com.apple.chronod/chronod" \
"$HOME/Desktop/chronod-backup/chronod-$(date +%Y%m%d-%H%M%S)"
killall chronod 2>/dev/null
killall NotificationCenter 2>/dev/null
如果执行时提示 Operation not permitted,需要先给终端完整磁盘访问权限:
系统设置 -> 隐私与安全性 -> 完全磁盘访问权限
给 Terminal 或 iTerm 授权后重新执行。
这个操作会重建小组件和通知中心相关缓存,一般不会影响应用数据。部分小组件可能需要重新加载或重新添加。
在 Windows 上,我们可以通过 NTFS 压缩功能让文件“原地变小”而不改变使用方式。macOS 虽然底层文件系统(APFS/HFS+)也支持透明压缩,但系统并没有提供图形界面开关。
applesauce 是一个命令行工具,可以调用 macOS 原生压缩能力,实现对文件的透明压缩——压缩后的文件仍在原位置,双击正常打开,但磁盘占用空间显著减小。
一键在 Chrome 侧边栏打开 DeepSeek,支持页面缩放并记忆缩放比例。
https://chromewebstore.google.com/detail/deepseek-sidebar/gakblhcadiegnapiajgolefjhhmicobi
git clone https://github.com/misswell/deepseek-sidebar.git
chrome://extensions├── manifest.json # MV3 扩展清单
├── background.js # Service Worker,处理图标点击
├── sidepanel.html # 侧边栏页面
├── sidepanel.js # 缩放控制逻辑
├── rules.json # 移除 X-Frame-Options 响应头
├── privacy-policy.html # 隐私政策
└── icons/ # 扩展图标
├── icon16.png
├── icon48.png
└── icon128.png
| 权限 | 用途 |
|---|---|
| sidePanel | 在 Chrome 侧边栏中展示 DeepSeek 页面 |
| activeTab | 点击扩展图标时获取当前标签页以打开侧边栏 |
| storage | 本地保存用户的缩放比例设置 |
| declarativeNetRequest | 移除 DeepSeek 的 X-Frame-Options 响应头,使其可在侧边栏中加载 |
| host_permissions | 访问 chat.deepseek.com 以实现上述头部修改 |
本扩展不收集任何用户数据。详见 隐私政策。
MIT
Yarn 安装完成后存在超时提示
success Already up-to-date.
✨ Done in 0.11s.
info There appears to be trouble with your network connection. Retrying...
info There appears to be trouble with your network connection. Retrying...
问题 :Yarn 的版本检查机制
Yarn 每次运行时可能会尝试连接网络检查自身版本或发送统计数据,即使不需要下载包。
解决方案:禁用版本检查和统计
# 禁用 Yarn 的版本检查
yarn config set disable-self-update-check true
# 禁用匿名统计数据上报
yarn config set analytics false
最近想给电脑设置开机后自动启动 VMware 里的几个虚拟机(Win7、CentOS、Win11),结果发现了一个让人抓狂的问题:明明在“配置自动启动虚拟机”里添加了,但重启后只有 Win7 和 CentOS 乖乖启动了,Win11 却纹丝不动。更诡异的是,在自动启动配置列表里压根就找不到 Win11 的身影!
经过一番折腾,终于把这个坑填平了。下面把踩过的坑和解决办法分享给大家。
Continue reading VMware Workstation 虚拟机自动开机攻略:Win11 不显示的坑与解法