内网终端浏览器锁死升不了，页面白屏，是我们改代码还是让客户换机器？

多数情况下，不需要为这一个客户另起一套前端。按 2026 年常见交付经验，旧版浏览器白屏大多落在语法层和 API 层，把构建目标降下来、按需引入 polyfill，主流程通常就能跑通；只有阻断点大面积集中在布局和组件交互上，才需要讨论独立低配版。要不要投，看三件事：这类终端占多少、承载的是不是必须完成的业务动作、甲方能不能提供一台真实可复现的终端。

白屏到底卡在哪一层

旧版浏览器白屏，处理方式要按层分，混在一起讨论最容易返工。

• 语法层：可选链、空值合并、类静态字段、顶层 await、ES 模块写法出现在产物里，旧内核解析阶段直接抛 SyntaxError，整包脚本不执行，表现是一整片白。
• API 层：语法能过，但用到 Promise.allSettled、Array.prototype.flat、fetch、IntersectionObserver 之类，报运行时错误，页面骨架在、内容出不来。
• 渲染层：脚本正常，只是 flex 的 gap、grid、CSS 变量不被支持，表现为布局错位、弹层飞出屏幕，而不是白屏。

定位顺序建议固定：在目标内核里打开页面，先看控制台第一条报错。语法报错往构建配置查，提示方法不存在往 API 查，视觉错乱再回头查样式。跳过这一步直接改代码，返工概率明显更高。

四条路的改动范围和代价差在哪

同样一句「要兼容旧浏览器」，落到方案上改动范围差很远。下面周期都是经验区间，随页面量和终端分布浮动。

• 方案 A：下调构建目标 + 入口按需 polyfill。改动集中在构建配置和入口，常见周期 3 天到 3 周；代价是产物体积上涨，新终端上执行略慢。
• 方案 B：兜底页 + 提示升级。只做能力检测，不满足就跳静态提示页，常见 1 到 3 天；适合旧终端占比低、又不在核心路径的情况。
• 方案 C：独立低配版。独立路由或模板，只保留核心流程，常见 3 周到 2 个月；长期是双份回归测试、双份发版检查。
• 方案 D：推动换终端或升浏览器。不动代码，周期看沟通，适合终端数量少、能面对面推动的场景。

A 和 B 并不冲突。不少项目是 A 兜主干、B 兜住个别确实跑不动的老内核；先上 B 再补 A，上线节奏不容易被兼容问题拖住。

交付现场：预算只够一轮回归时怎么排

比较典型的约束是这样：甲方内网两百多台终端，其中一部分是随设备出厂的内嵌浏览器���操作系统和浏览器都不能自行升级，页面素材由甲方提供且不能改，交付期给三周，预算只够一轮完整回归。

做法是先把范围缩到「主流程可用」，而不是追求全站视觉一致：把构建目标降到该内核支持的语法级别，polyfill 只在入口按需引一次；依赖 grid 和 gap 的页面改成 margin 方案；剩下两个复杂图表页用静态图兜底，并在页面上写清说明。页面量在几十个的时候，这一档改动常见区间是三到十天，图表页兜底大约每页半天到一天。

结果是主流程能跑通，两个图表页降级，回归多花了约四天，工期整体后延一点。代价提前写进交付文档和降级清单，比验收当天再解释省事得多。

验收口径和两个容易踩的误判

• 目标内核上，主流程关键路径（登录、列表、表单提交、文件上传、支付跳转等，常见 8 到 12 条）全部可完成，无白屏、无阻断性报错。
• 控制台不出现语法级错误；残留的运行时告警要有清单，不能只写一句「已知问题」。
• 有书面降级清单，逐条写清哪些功能在该内核不可用、替代方式是什么。
• 记录终端基线版本，后续每次发版按这条基线回归，不靠记忆和口头传。

误判一：只在开发者工具里把 UA 改成旧版就当验过。改 UA 只影响服务端判断和少量样式，浏览器 JS 引擎没变，语法级失败根本复现不出来，必须用真实内核或对应版本的真机跑。误判二：只跑首页截图。旧内核挂掉多半在详情、上传、支付这类交互路径上，得按主流程一条条走。结论拿不准时，写「未验证」比凭推测签字稳。

什么情况该投，什么情况不必

边界相对清晰：终端由甲方统一管控、不能自行升级、且承载的是必须完成的业务动作，兼容就属于交付范围内的硬需求；反过来，公网产品、用户能自己升级浏览器、旧终端只占个别比例又不落核心路径，用兜底页提示升级通常就够，不必动整套工程。

• 适合投入：内网办公、行业设备内置浏览器、政务或医疗终端、客户统一发机器的私有化部署项目。
• 不必上：终端版本分散但都可升级的公网产品、旧终端访问占比很低、被兼容页面只是展示类信息。
• 要提前问清：甲方能否提供一台真实终端或可复现的内核版本，这直接决定后面是测得准，还是只能猜着改。

常见问题

只加 polyfill 不改构建目标，旧浏览器还会白屏吗？

会。polyfill 补的是运行时 API，补不了浏览器看不懂的新语法；产物里出现可选链或 ES 模块写法，脚本仍会在解析阶段整体失败。

客户说终端不能升浏览器，是不是只能重写一套？

多数不用。先统计阻断点落在语法、API 还是布局层，前两层靠构建配置和按需 polyfill 就能覆盖，只有布局与组件大面积不兼容才需要考虑独立低配版。

内网旧终端占多少，才值得专门做兼容？

没有统一阈值。按 2026 年常见交付经验，旧终端承载核心流程且占比达到一两成以上时，方案 A 的投入基本划算；占比很低又不落核心路径，兜底页更合适。

兼容做完之后要一直维护吗？

不必长期背着。可在合同或交付文档里约定支持的内核基线，每年评估一次终端分布，占比降到很低时提前发下线通知，再停止回归。

如果手上正好有这类项目，建议先做一件事：拿一台真实目标终端把主流程跑一遍，记下控制台第一条报错，再决定投哪一档。犀跃公司在私有化交付场景里通常按先测后改的顺序排期。需要提醒的边界是：终端基线一旦定下就要写进文档，没有基线的兼容工作，下一轮发版很容易又被推翻。