序章：分裂的天空
私有化交付的三大挑战
站在出发点的悬崖边，你望向远方——每座岛屿都笼罩在不同的迷雾中。有的被紫色孢子覆盖（信创系统），有的在永夜中闪烁微光（纯内网），有的位于狂风暴雨之中（弱网环境）。甚至有座岛屿完全沉入地下矿洞，与世隔绝（完全离线）。
每座岛屿的独特环境 = 不同的客户环境（浏览器、操作系统、网络条件）
- 纯内网环境、偏远山区弱网、矿洞井下完全离线
- 常规浏览器 vs 功能缺陷的 WebView
- 信创操作系统、鲲鹏CPU虚拟机
- 要求：极致的兼容性和接口统一性
你检查背包里的飞行器——这是一台古老的蒸汽动力滑翔翼。燃料有限，引擎老旧。你不能像云端城市的人那样肆意飞行，必须精打细算每一滴燃料，在前进（前端计算）与借力气流（后端支援）之间找到平衡。
有限的燃料和老旧引擎 = 客户受限的服务器资源和带宽
- 私有化客户服务器资源受限，带宽捉襟见肘
- 不能把所有计算丢给后端
- 客户端需要分担压力，但有时客户端又很孱弱
- 前后端传输量需要在网络阻塞环境下尽量减少
地图显示，你不能只是"到达"这些岛屿——它们的生命树根系早已与各自的城市系统（OA审批、知识库、工作流）深度缠绕。要重建通信，必须让你的信号融入这些根系，成为它们的一部分，而非外来者。
与城市根系融合 = 与客户系统深度集成（嵌入OA、审批流程、知识库）
- 客户会把Office嵌入OA系统、审批流程、知识库检索
- 需要全面完善的接口系统
- 统一的标准化规范
- 低门槛的接入方式
- 否则联调过程对双方都是噩梦
第一章：双镜之桥
WebOffice SDK 双代理架构
你来到第一座遗迹——两座相对而立的水晶塔，中间隔着一道无法穿越的力场屏障（iframe隔离）。但你发现了古老的通信法阵：在两塔各放置一面魔法镜（双代理），它们会将你的话语转化为光束穿过力场，再由对面的镜子还原成声音。
两面魔法镜 = SDK侧代理 + WebOffice侧代理，光束传输 = postMessage序列化通信
- iframe是严格的隔离沙箱，只能通过postMessage传递序列化消息
- SDK侧代理：监听用户调用，把链式调用翻译为序列化消息
- WebOffice侧代理：把消息还原为真实的对象调用
- 目标：让客户像调用本地VBA一样使用链式调用
- 例如：sdkInstance.Application.ActiveDocument.Range.Text
塔中的守护精灵交给你一本会自动更新的魔法词典（API结构树）。它记录了对面城市所有能听懂的语言和指令。词典会在每次连接时自动同步最新内容，这样你永远不会说出对方听不懂的话——那些无效的请求会被词典提前拦截。
魔法词典 = API结构树，自动更新 = 动态适配WebOffice版本迭代
- 为兼容IE11，需要降级到defineProperty建立代理，必须提前知道接口属性
- WebOffice收到ready消息后，深度遍历Application对象的所有子属性
- 根据类型生成扁平化的描述结构
- 三大好处：
① SDK可预判调用是否合法，避免无意义通信
② 动态适配，API迭代时结构树自动更新
③ SDK发版频率从一年15次降到1次
频繁的光束传输会消耗魔力。于是你在两塔之间布置了三层记忆水晶：第一层记住你发送过的消息结构，第二层记住传输过的完整路径，第三层由对面的塔记住已解析的结果。下次发送相似消息时，水晶直接给出答案，光束只需传输变化的部分。
三层记忆水晶 = SDK侧代理缓存 + 链路缓存 + WebOffice侧缓存，90%复用率
- 第一层 - SDK侧代理对象缓存：Application只创建一次，ActiveDocument代理对象也会被缓存，只有终端节点不缓存（因为值可能变化）
- 第二层 - 链路缓存：第一次调用发送四条消息，第二次只发一条
- 第三层 - WebOffice侧缓存：收到获取ActiveDocument的消息时写入缓存，下次直接取值
- 典型场景下，缓存复用率达到90%以上
第二章：风暴中的灯塔
离线编辑的命令合并策略
飞入永夜风暴区，你与所有岛屿失去联系。但旅途不能停止——你必须继续记录沿途发现（编辑命令），等待风暴过后一并发送。问题是：如果记录太多，目的地的译码塔（内核OT算法）会过载崩溃，它最多只能处理128条消息的差异计算。
永夜风暴 = 断网环境，译码塔过载 = OT算法128版本限制
- 用户在弱网/无网环境下的数据恢复问题
- 在线流程：用户操作 → 编辑命令 → 内核产生版本 → OT算法冲突计算
- 离线时无法实时与内核沟通，命令只能暂存本地
- 关键限制：内核OT计算上限为128个版本差异
- 最坏情况：用户反复删改几个字就超限，这不是可用的离线编辑
你掌握了两种初级分拣术：当信件少于100封时，原样保存，保持完整记录（无合并）；当超过100封时，把每10封装入一个大信封（batch命令），这样译码塔只需处理10个版本。这个方法很机械，但足够应对中等风暴。
100封原样 = 阶段一无合并，大信封 = 阶段二batch机械合并（10:1压缩比，上限1000条）
- 假设容量配置为100
- 当原始离线命令总量≤100时，不做任何合并
- 重连后直接发送原始命令，保持完整操作历史
- 命令超过100时，利用batch命令机制
- 按配置比例（如10:1）将若干原始命令作为batch子命令
- 内核根据batch产生版本，绕过128版本限制
- 比例上限取决于内核处理时间（OT计算开销）
- 第二阶段承载上限：100 × 10 = 1000条
当信件超过1000封时，你启动了古老的"时光织布机"（LCS算法）。它不关心你写信的过程，只对比风暴前后的两张照片——起点状态与终点状态。织布机在二维网格上寻找最长的相同线索，然后用最精简的指令重建差异。如果你反复修改最终又改回原样，织布机会说："什么都没变。"
时光织布机 = LCS最长公共子序列算法，二维网格 = 动态规划填表
- 当原始命令超过1000条时启用
- 核心思路：不关注中间过程，只关注初始状态和最终状态的差异
- 离线开始时导出全文状态快照（文本、位置、长度、样式）
- LCS动态规划：
- 用两个状态的文本构建二维表格
- 字符相等：填入斜下方值+1
- 不相等：取右侧或下方最大值
- 逆向回溯：向下=删除，向右=插入 - 后处理：命令聚合（合并连续相同操作）+ 转换全局坐标
- 极端案例：用户反复修改同一段最终改回原样 → 合并率100%，操作为0
不管用什么分拣术，原始信件始终被封存在防火保险箱（IndexedDB）中，直到确认送达。如果织布机计算出错，你还有后手：复制全文、导出原始日志、另存新卷轴。核心信条是：传递可以失败，但信件绝不丢失。
防火保险箱 = IndexedDB存储原始命令，后手方案 = 降级策略（复制/导出/另存）
- 核心原则：原始命令在合并确认前始终保存在IndexedDB中
- 离线编辑的本质：对用户承诺——没网也能放心编辑，内容不会丢失
- 多重保障：
- LCS校验失败或任意阶段合并出错
- 提供复制全文选项
- 提供导出原始操作日志
- 提供另存新文档（不会造成协作阻塞） - 核心原则：合并失败不可怕，关键是保证用户内容安全
第三章：水晶档案馆
极速预览技术
最后一站是传说中的水晶档案馆——收藏着数千页的古老典籍。传统的阅读方式是：管理员（内核）必须先把整本书搬出来、翻译、装订，你才能看第一页。这需要等待10秒以上，而且书太大时，阅览室（内存）会被压垮，翻页卡顿甚至崩溃。
古老典籍 = 企业知识库大文档，传统阅读 = 编辑预览共用代码，首屏5-10秒
- 场景特点：政企客户预览频率远高于编辑，历史文档普遍内容巨大
- 传统方案问题：
- 预览和编辑共用一套代码
- 未执行的静态资源占80%以上（编辑功能JS+UI组件）
- 冷启动首屏加载5-10秒
- 千页文档加载更慢 - 流程开销：内核下载→解析→编译→长链接发送→前端解析→排版计算→绘制转换
- 性能问题：内存持续升高、超大文件滑动卡顿、低性能机器浏览器崩溃
你发现了新的阅读法：每本书入馆时，就被工匠预先雕刻成一片片水晶页（SVG），存入悬浮的储物格（对象存储）。阅读时，你只需报出书名和页码，水晶页就会飞到眼前。不需要管理员，不需要翻译，瞬间可读。
预刻水晶页 = 入库时预转换SVG，悬浮储物格 = 对象存储按需获取
- 预转换机制：文档入库即触发预转换
- 内核读取、解析、排版、导出SVG序列
- 推入对象存储 - 前端获取：根据文件ID拼接对象存储地址，无需与服务端通信
- 代码独立：预览前端完全独立，不与编辑共用
- 只保留必要基建
- UI和交互完全重新设计
- 静态资源降低90% - SDK轻量化：主动更新Token、多种鉴权方式、非鉴权场景SSR加速
阅览台被设计成一个旋转装置（虚拟滚动）：只有眼前可见的几页水晶会浮在台面上，当你翻到下一页时，离开视野的页面会自动收回格中，腾出空间给新页面。无论典籍有多少页，台面上永远只有固定数量，阅览室永不拥挤。
旋转阅览台 = 虚拟滚动，收回格中 = DOM节点回收复用，始终渲染固定数量页面
- 不需要拉取元数据进行提前排版计算，实现真正的按需加载
- 预加载区域只跟视窗位置相关
- 页面滚动超出视窗后回收DOM节点给新页面使用
- 控制DOM数量和内存占用
- 效果：
- 滚动流畅度不受页数影响
- 始终只渲染固定数量页面
- 内存保持在低水平
- 数千页文档操作帧率与普通文档无差异
水晶页的文字必须用原始的墨水（字体）才能正确显现。你召唤了一位字体精灵：它会用两块画布测试——如果你的墨水画出的字与标准墨水完全相同，说明你已拥有这种墨水；如果不同，精灵会从远方调取，并存入你的墨水盒以供下次使用。
画布测试 = canvas对照位图检测，墨水盒 = IndexedDB字体缓存
- 核心需求：后端排版、前端绘制，必须保证字体一致才能布局正确
- 检测方法：
- 定义两段文本，字体设置为 a,b 和 b
- 写入canvas导出为AB两个对照位图
- 如果AB像素完全一致，说明字体a没有应用上（本地不存在） - 按需加载：
- 检测到缺失后请求webFont
- 存入IndexedDB便于下次复用 - 与编辑服务共用字体缓存策略，可复用编辑服务的字体缓存数据
尾声：新航线的开辟
未来规划
旅程完成，但新的航线正在绘制。你在星图上标记了三个方向：让镜面传音塔支持多重连接（SDK多实例）；让时光织布机学会处理色彩和符文（离线编辑二期）；让水晶阅览术适用于所有类型的典籍（PDF极速预览）。更远的地平线上，AI协助者的身影若隐若现……
三个标记 = SDK重构/离线二期/PDF预览，AI协助者 = AI与Office结合探索
- SDK方向：
- A级项目评审立项
- 已完成SDK多实例和多平台统一重构
- 同一页面可同时创建多个文档实例
- 整合公网/私网开放平台SDK，对外输出一份标准SDK - 离线编辑二期：
- 目前只支持纯文本的大容量操作
- 规划支持更丰富操作类型：字体、字号、颜色、书签、修订、超链接等 - 极速预览扩展：
- 两年多交付验证，已非常稳定
- 正逐步取代普通预览模式
- PDF已支持完整极速预览模式 - AI探索：AI模型可配置化接入、文档操作接口在自动化流程中的应用