看一个 Chrome 扩展时，很多人第一反应是：它是不是要连作者自己的服务器？数据是不是都存在云端？另外，用 Cursor 这类 AI 编程工具时，也常会把 Usage、Context、CPU 这些词混在一起。
这两个问题看起来不相关，但背后都在问同一件事：一个工具的“状态”和“用量”到底属于本机、浏览器、账号，还是模型上下文。
这篇按备忘的方式整理一下。
怎么判断一个项目是不是 Chrome 扩展
以 TabCard 这类新标签页收藏管理工具为例，判断它是不是浏览器扩展，可以先看几个文件和配置。
典型特征包括：
- 有
manifest.json或manifest.config.ts。 - 使用 Manifest V3。
- 通过
chrome_url_overrides.newtab接管新标签页。 - 权限里出现
storage、tabs、activeTab、favicon等。 - 构建后需要在
chrome://extensions里加载dist目录。
如果这些特征都出现，它基本就是 Chrome 扩展，而不是普通网页应用。
Chrome 扩展的数据通常存在哪
很多轻量扩展不一定会自建后端服务器。更常见的是先使用浏览器提供的存储能力。
常见选择可以这样理解：
chrome.storage.local：扩展本机存储，适合配置、收藏、轻量数据。chrome.storage.sync：可随 Chrome 账号同步的小体量配置。localStorage：当前同源下的本地存储，有些扩展会作为镜像或兼容层。- IndexedDB：更适合结构化和体量稍大的本地数据。
所以，“没有看到作者服务器”不等于“没有保存数据”。它可能只是把数据存在浏览器本机。
反过来也要注意：用了浏览器本机存储，不代表所有数据都安全同步到别的设备。比如 storage.sync 适合同步小配置，不适合塞大量收藏、截图、网页正文或图片。
能不能把扩展数据当 1GB 云盘用
一般不能这么想。
Chrome 的 storage.sync 配额很小，适合小配置；storage.local 默认也不是无限空间。即使用了 unlimitedStorage 权限，也不应该把它理解成“保证 1GB 可用”。
如果扩展要存大量数据，更合理的设计通常是：
- 小配置放
chrome.storage.sync。 - 本机常用数据放
chrome.storage.local。 - 大一点的结构化数据放 IndexedDB。
- 真正需要多端稳定同步时，再考虑后端账号体系或第三方同步方案。
也就是说，先分清“本机可用”和“多端同步”是两件事。
Cursor 里的 Context 是什么
Cursor 这类 AI 编程工具里，Context 通常指当前对话或任务能塞进模型的上下文窗口。
会占 Context 的内容包括：
- 当前聊天历史。
- 你给它的规则和说明。
@进去的文件。- 工具返回的大段内容。
- 代码片段、报错、diff 和终端输出。
Context 接近 100% 时，不是你的电脑 CPU 爆了，而是这轮对话快装不下更多上下文了。继续塞材料时，早期内容可能被压缩、裁剪，或者模型对旧细节记得不稳。
这时比较实用的处理方式是：
- 新开一个 Chat。
- 用几段话总结当前目标、关键文件和已做决定。
- 少贴整份日志，优先贴关键报错和相关代码。
- 对很长的项目，让工具按需读取文件，而不是一次性塞一堆。
Usage 不是本机 CPU
Usage 更像账号侧的 AI 用量或套餐消耗。不同版本、不同产品文案可能会变化，但它通常不是指本机 CPU、内存或风扇压力。
可以粗略区分：
- Context：这轮对话装了多少上下文。
- Usage：账号侧 AI 调用或套餐用量。
- CPU / 内存：本机资源占用，通常要看系统监控。
如果 Cursor 显示 Context 很高，重点是减少这轮对话的上下文负担；如果 Usage 用得快，重点是看模型、模式、套餐和请求次数；如果电脑卡，那才应该去看 Activity Monitor、任务管理器或系统监控。
为什么代码比普通文字更占上下文
很多人会问：Context 100% 大概等于多少字？这个没有固定换算。
模型通常按 token 处理文本，中文、英文、代码、路径、符号的 token 密度都不一样。代码里有大量缩进、标点、变量名、路径、JSON、日志，比普通段落更容易占上下文。
所以更稳的习惯是：
- 让 AI 只读相关文件。
- 贴报错时保留首尾和关键栈帧。
- 大 JSON、大日志先压缩成问题摘要。
- 改代码时给目标和边界，不要把所有历史都贴一遍。
这比纠结“还剩多少字”更有用。
小结
Chrome 扩展和 AI 编程工具都要先分清数据边界。
Chrome 扩展的数据可能存在浏览器本机、Chrome 同步、小型本地存储或 IndexedDB 里；除非项目明确接了后端，否则不要默认它有作者服务器。Cursor 里的 Context 主要是模型上下文窗口，Usage 更偏账号侧 AI 用量，它们都不是本机 CPU。
以后看类似工具，可以先问三件事：
- 数据存在本机、浏览器同步，还是作者服务器？
- 当前限制来自存储配额、账号用量，还是模型上下文？
- 如果要长期使用，是否需要导出、备份或同步方案？
把这三层分清楚，很多“工具到底把东西放哪了”“为什么突然满了”的问题就好判断了。
