你的书库只属于你

书库条目、下载的文件、封面缓存、读书笔记、画布笔记、批注与阅读进度，全部写在本机的数据目录里。没有账号，没有同步服务端，没有遥测上报。

AI 对话记录同样只存在本机，按会话分别存成文件，随书籍删除一并清理。发给视觉模型的图像也留在本地，供你回看历史时显示，后续追问不会重复上传。

Windows

程序目录同级的 data/，便携布局。整个程序目录可以整体搬走或备份。

macOS

~/Library/Application Support/PeopleLib。应用包在 DMG 里是只读的，数据不能放里面，升级覆盖也不会碰到这个目录。

想彻底删除数据，删掉上面对应的目录即可，不需要在任何地方注销账号。

应用没有内置任何厂商服务，也没有代理转发层。你在设置里填自己的接口地址与 API Key， 请求从你的机器直接发到你填的那个地址。项目方看不到你的用量，也收不到你的费用。

• 密钥加密落盘：API Key 经操作系统提供的 safeStorage 加密后保存，不是明文配置文件。
• 密钥不进渲染进程：界面进程拿不到密钥原文，实际请求由主进程发出。
• 密钥不写日志：日志与错误信息里不会出现密钥或 token。
• Responses 协议不留存：走 OpenAI Responses 协议时请求带 store: false，不让服务端留存对话记录。

注意：你选择的模型提供方会按它自己的政策处理收到的内容。PeopleLib 能控制的是不多发、不留副本、不经第三方转发。

打开一本书不会触发任何 AI 请求。只有你选定上下文范围并点击发送，内容才会离开本机。

• 选择「全文」范围时，无论文档多短都会强制弹出确认框，并提示可能超出模型的上下文限制。
• 确认框里显示的字数就是真正外发的字数。应用不做本地截断，界面数字与实际请求一致。
• 如果内容超出模型限制，应用把接口返回的报错转成中文提示，而不是悄悄少发一部分。

这条规则有过教训。早期版本按固定字数上限挖掉正文中间部分，结果 40 页的文档实际只发出 8 页， 而界面仍显示全文字数。那属于静默的数据丢失，用户还会把答非所问归因于模型，所以该行为已经移除。

Electron 应用最常见的风险是渲染进程能拿着任意路径去读盘。PeopleLib 把这条路堵住了： 渲染层不能传任意路径，所有文件访问都要经主进程的白名单校验，只放行书库中真实登记的条目。

• 路径白名单：不在书库里的路径一律拒绝，无论渲染层怎么构造参数。
• 会话与发送方绑定：超大 PDF 的分段读取会话与请求方绑定，句柄不透明，界面窗口销毁后立即回收。
• Markdown 双重净化：Markdown 渲染禁用裸 HTML，再过一层 DOMPurify，防止文件内容里的脚本被执行。

带 DRM 的 MOBI、AZW、AZW3、KFX 与 Topaz 文件，以及损坏或不兼容的文件，应用不会尝试解除保护。 遇到这类文件会直接给出提示，建议改用系统关联的应用打开。

同样地，PeopleLib 只是对公开网络接口的客户端封装，不托管也不分发任何内容。 各数据源所提供作品的版权状态因司法辖区而异，使用者需自行确保用法符合当地法律与各站点的服务条款。

所有这些请求都走你在设置里配置的全局代理，包括封面请求。

本站是托管在 GitHub Pages 上的静态页面，没有分析脚本，没有 Cookie，没有第三方字体或 CDN 资源， 页面用的是你系统里已有的字体。作为托管方，GitHub 会按其自身政策记录访问日志，这一点本站无法控制。