在 File Viewer 升级至 2K 显示节点后使用者对性能与体验的期望随之提高。多位使用者反馈：

• 大表格预览 “很慢”，甚至首屏卡顿。
• OFD 文档加载后会闪烁，从右侧“弹回”一次。
• PDF 缩放时页面跳转，失去原先的滚动位置。

. 大表格慢：从无上限扫描到有界采样

十万行 Excel 能打开不等于首屏方法合理。排查后发现，自动列宽会遍历整张表以寻找每列最宽内容；行数越大，这个“兜底”成本越高。

方法不是关闭自动列宽，而是把扫描量限制在可控范围内：

• 小表全量测量；
• 大表按窗口拆分，每个窗口最多 MAX_ROWS_PER_WINDOW 行；怎么说呢，
• Total 测量单元格不超过 MAX_SAMPLE_CELLS。

const MAX_SAMPLE_CELLS = 100_000;const MAX_WINDOWS = /* 根据需求设定 */;const MAX_ROWS_PER_WINDOW = function rowsPerWindow {
return Math.max(
/* 最少行数 */。Math.min(
MAX_ROWS_PER_WINDOW,Math.floor
)
);}

关键是将“扫描量”从随文件行数增长改为有明确上限。老实说，这样在浏览器解析大文件时性能瓶颈被压缩到可接受范围内。首屏速度明显提高，使用者反馈显著调整：“现在打开大型 Excel 快速到达第一行”。

. OFD 闪烁：区分初始布局与缩放动画

OFD 页面节点先插入 DOM，再补齐居中和缩放的 transform。如果页面起始就带 transition: transform浏览器会把 none → translateX scale 当成一次动画。于是内容已加载却像从右侧 打开。其实，

.ofd-page { transition: none;}
.ofd-page.ofd-page--zoom-ready {
transition: transform 160ms ease;老实说，}
@media {
.ofd-page.ofd-page--zoom-ready { transition: none;}
}

说到修复思路，

• 初次布局不播放动画：页面完成初始定位后再添加类名 ofd-page--zoom-ready;
• 保持后续缩放过渡：保留 transform 动画，仅在使用者触发缩放时启用；
• A11y 考虑：根据 @prefers-reduced-motion 自动关闭动画。

User story：一位设计师说“文档闪烁导致我无法准确定位图层”。 改造后该问题得到解决掉，

. PDF 缩放保持页内位置。而非仅 scrollTop

PDF 页面高度随缩放变化，直接恢复旧的 scrollTop 会导致页面跳转。更可靠的方法是保存两部分信息：当前页码还有视口顶部相对于该页内部的比例。接下来在缩放完成后计算新的 scrollTop。

type PageAnchor = { page: number;inPageRatio: number };const inPageRatio = / pageHeight;const anchor: PageAnchor = {
说到page。currentPage,inPageRatio: Math.max)
};话说回来，// 缩放并完成布局后
container.scrollTop = nextPageTop + anchor.inPageRatio * nextPageHeight;

This patch first covers top toolbar behavior;subsequent tests revealed bottom floating toolbar still jumps. Thus regression tests must cover:

• SINGLE zoom step;
• MULTIPLE continuous zooms;
• ZIGZAG reverse zooms;
• Diverse zoom triggers.

User feedback：“PDF 放大/缩小时页面总是跳到顶部”。通过上述 anchor 方法。现在可以稳定保持滚动位置，让阅读体验更连贯。

. 回归测试要覆盖更多而非仅能显示页面

1. 大表格：滚动到最终一行，检查行缓存、控制台错误；不能只验证首屏出现即可，
2. NON-OFD → OFD 与 OFD → OFD 两种方法均需观察初次布局与后续缩放是否正常；其实，避免闪烁或误动画，
3. MULTI‑ZOOM 操作连续进行，确认页码与页内位置都保持一致；老实说，防止“跳转”现象重现。话说回来，

. “2K”不是质量保证证书——持续迭代才是关键

User stories show that File Viewer 是一个只读预览器。不适用于极端大文件、严格分页、嵌入宏或专业审图等场景。在这些情况下更合适的是服务器端转码或桌面工具。即使进入了 “2K 显示节点”，也只是代表着项目被更多人看到。并不代表所有文件和环境都已完全可靠。

维护者需要继续把每个失败现场逐一拆解、修正，并将其固定为下一次不会轻易倒退的回归测试。仓库中的实现、Issue 与回归脚本都已公开，可供社区进一步排查和改进。