为什么 Codex Provider Sync 同步这么快揭秘原地字节更新与流式替换两大落盘策略【免费下载链接】codex-provider-syncSynchronize Codex session provider metadata across rollout files and SQLite state.项目地址: https://gitcode.com/gh_mirrors/co/codex-provider-syncCodex Provider Sync 是一个本地工具负责把 Codex 会话的 Provider 元数据在 rollout 会话文件与 SQLite 状态之间保持一致——当你的当前配置切换到新 Provider 后它会把历史会话文件里的 Provider 信息对齐过来让旧会话可以继续用。很多用户关心一个问题会话文件动辄几十 MiB全量重写一遍不是慢死了其实它靠的是原地字节更新和流式替换两大落盘策略核心原则只有一句只动该动的字节正文一个字节都不碰。痛点为什么完整重写是最慢的做法一次普通的 Provider 同步真正要改的只有session_meta里的model_provider这一个 JSON 字段但 rollout 文件里还装着你全部的聊天记录。如果像传统做法那样把整个文件读出来、改一个字段、再完整写回几十 MiB 的正文要完整读取一遍生成一份同样大小的临时副本再做一次文件系统替换读、写、替换三个动作的成本全都花在了一个几乎没变的字段上。Codex Provider Sync 的架构决策文档明确否定了这条路线ADR-0015 把等长原地更新定为性能基线后续的 ADR-0016 进一步把它固定为 Node Core 的默认行为。策略一原地字节更新PIO-2只覆写 Provider 那几十字节这是快同步的核心。当新旧两个 Provider ID 满足条件时同步器不复制任何文件而是用文件句柄直接定位到model_provider字面量的字节偏移只覆写那一段新旧 ID 都匹配[A-Za-z0-9._-]且JSON.stringify后的UTF-8 字节长度相同注意是字节不是字符数首行中model_provider位置唯一、原始字面量与预期一致本次不需要历史模型重写、无多个硬链接目标这些资格检查由 getInPlaceProviderMutation 完成成功落盘后结果里计入inPlaceSessionFiles。效果非常直接文件身份不变、文件大小不变、首行以外的正文哈希不变实际写入的字节数就等于 Provider JSON 字面量的长度。也就是说改一个 Provider 的 I/O 量从整个文件降到了几个字段字节。Windows 上通过内置的 PowerShell worker 和 windows-provider-bytes.cs 执行同一套句柄协议POSIX 使用已校验的同一句柄定位写入两端行为一致。策略二流式替换PIO-3不等长时正文仍逐字节保持新旧 ID 长度不同时比如从openai切到更长的自定义 ID原地覆写会让后面所有字节错位此时自动切换到第二条路径在同目录创建临时文件只重写首行更新 Provider 字段保留 LF/CRLF 分隔符剩余正文以有界流式方式逐块复制不解析、不重序列化校验后原子替换原文件这条路径允许文件身份变化结果计入rewrittenSessionFiles但正文保证逐字节一致——你看到的聊天记录与之前完全相同。关键点是流式复制只负责搬砖绝不做业务解析所以即使文件再大也不会因为解析 JSON 而产生额外内存与时间开销。 两种策略的选择完全由 Core 自动完成你不需要把 Provider 改成固定长度也没有隐藏的--fast开关——它就是默认行为。为什么同步器只需要看第一行两大落盘策略能成立还有一个前提业务扫描边界只在首行。普通 Sync 始终取config.toml根级model_provider作为目标缺失时默认openai扫描时只解析每个 rollout 的第一行session_meta见 PIO-1 说明绝不会为了查模型、cwd 或历史索引去翻几十 MiB 的正文。加密内容只诊断、不修改其他字段历史 model、title、SQLiteupdated_at等一律不碰。提速不减安全落盘顺序有严格约束速度快不代表可以牺牲可靠性。每次写入都遵循固定顺序PIO-5消费一次性 PlanHome 锁内复核快照与占用状态无变更目标时直接返回不创建备份先做 UndoBackup默认保留 2 份再执行首次写入——首次 mutation 前失败意味着零业务写入中途失败会返回带backupId与阶段信息的partial结果重新执行即可收敛也可手动 Restore一个容易误解的细节原地写失败时同步器不会偷偷降级成整文件替换来绕过失败而是明确报错。宁可失败不可绕过。如何确认这次同步真的走了快速路径同步结果与操作日志会如实报告两种策略各自的实际数量。当一次操作实际重写的会话文件达到 100 个以上时桌面端结果窗口才会出现默认折叠的查看提速建议提示展示规则见 ADR-0036它只控制提示展示不是性能门禁。你也可以展开概览页的如何加快同步说明了解当前 Provider 是否适合原地更新需要手动压测时可以运行 benchmark-provider-io.mjs 生成参考数据但项目明确不以 wall-clock 作为门禁——真正的验收由 provider-sync-lite.test.js 这类测试保证写入字节数精确等于字面量长度、正文尾哈希不变、文件身份与大小不变、每个 rollout 正文至多扫描一次。快速参考想深入了解看这里原地字节更新的原始决策docs/adr/0015-provider-byte-updates-and-fast-sync.md当前落盘策略与 PIO-1PIO-6 不变量docs/architecture/NODE_CORE_ARCHITECTURE_ZH.md原地写与流式替换实现src/session-files.jsWindows 端句柄协议 helpersrc/windows-provider-bytes.cs存储层四端口设计packages/core/src/infrastructure/codex-storage.js提速提示与日志布局docs/adr/0036-sync-performance-guidance-and-log-split-view.md一句话总结Codex Provider Sync 的快来自少干活而不是干得快——能原地覆写几个字节就绝不复制整个文件必须复制时正文也只流过一遍、一个字节都不改。【免费下载链接】codex-provider-syncSynchronize Codex session provider metadata across rollout files and SQLite state.项目地址: https://gitcode.com/gh_mirrors/co/codex-provider-sync创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考