Edge与Chrome兼容性冲突排查：四层差异与降级实战

浏览器兼容性这个问题，我原以为在 Chromium 一统天下的年代已经快绝迹了，直到上个月连着踩了三个坑：同一套后台管理系统，在谷歌 Chrome 里登录、跳转、导出一切正常，换到 Edge 上登录后弹窗关不掉；另一个数据看板反了过来，Edge 秒开，Chrome 白屏转圈十秒然后报超时；最离谱的是 PDF 预览模块，Edge 里汉字全是方块，Chrome 里却干干净净。三个问题看起来互不相干，排查到最后发现它们共享同一条线索——我们一直在用"都是 Chromium 内核"这个假设偷懒，而忽略了Edge、Chrome 浏览器兼容性冲突的真正来源从来不是内核本身，而是内核之外的版本节奏、厂商策略、扩展注入和 UA 探测这四层东西。这篇文章就是我把这三次排查过程完整复盘的结果：现象怎么描述、工具怎么选、根因怎么定位、代码怎么改、上线之后怎么防复发。前端、测试、运维，以及做桌面端壳套浏览器的同学都能直接拿去用，我不讲大道理，只讲我实际敲过的命令和改过的行。

1. 先把"冲突"翻译成能验证的问题

1.1 我手上的三个故障现场

第一个现场是弹窗关不掉。这个后台项目用的是 Vue3 + 自研组件库，登录成功后会弹一个二次验证弹窗，弹窗右上角有个关闭按钮。在 Chrome 上点一下就走emit('close')正常关闭，在 Edge 上按钮能点、能触发事件、控制台也打出了日志，但弹窗纹丝不动。第二个现场是数据看板白屏，Chrome 里 Network 面板能看到一个接口挂了 12 秒后返回 504，而 Edge 里同一个接口 200 毫秒就回来了。第三个现场是 PDF 预览乱码，我们用的是浏览器原生的 PDF 渲染，Edge 上中文字体全部显示为方块，Chrome 上完全正常。

这三个现象如果只用一句"浏览器不兼容"来概括，后面的排查就彻底没法做了。我的习惯是先把现象拆成三个维度：是必现还是偶发、是单个浏览器异常还是两边表现不同、异常发生在渲染层还是网络层。第一个问题必现、单边异常、渲染层；第二个问题必现、单边异常、网络层；第三个问题必现、单边异常、渲染层但根因在字体。拆完之后，问题的搜索空间立刻缩小了一半。

提示：别急着打开代码。先花十分钟用文字把现象写清楚，写成"在 X 浏览器上做 Y 操作，期望 Z，实际得到 W"这个句式。写不清楚的现象，基本也修不好。

1.2 同内核为什么会分叉：四层差异模型

很多人以为 Edge 和 Chrome 都是 Chromium，行为应该一致。这个认知在实际项目里会害死人，因为两家从 Chromium 主干分叉出去的节奏、裁剪和叠加都不完全一样。我一般把差异拆成四层来看。

第一层是Chromium 基线版本。两家跟进上游的节奏不同，同一时间你机器上的 Edge 可能比 Chrome 落后两到三个大版本，也可能反过来。Chromium 每个大版本都会带进来新特性、新默认值和新的废弃项，跨版本就差在这。第二层是厂商策略层。Chrome 的隐私沙盒、第三方 Cookie 分阶段策略、混合内容拦截默认值，和 Edge 上的企业策略、跟踪防护等级、SmartScreen 拦截逻辑，是两套独立的开关体系，很多是灰度下发的，同一个版本号在不同设备上的实际行为都可能不同。第三层是扩展与内置功能注入。这一层最容易被忽略，也最容易造成"我自己电脑上好好的，客户那边打不开"这种诡异现象。第四层是运行环境，包括 GPU 驱动、系统字体集合、区域设置、系统代理配置、DPI 缩放比例。

把这四层摆在桌面上，你就明白为什么"升级到最新版"不是万能药：升级只解决第一层，剩下三层该冲突还是冲突。

1.3 一个前置动作：最小可复现环境

在动 DevTools 之前，我一定会先做一次环境收敛，把偶发问题变成必现问题。这一步没有技术含量，但能省掉后面一半的无效排查时间。具体动作是四条：第一，用无痕窗口复现，排除缓存和旧 Cookie；第二，禁用全部扩展再复现，排除注入干扰；第三，把两个浏览器窗口拉到完全相同的尺寸和缩放比例，排除响应式断点差异；第四，固定网络条件，用 DevTools 的 Network Throttling 选"Fast 3G"再试一次，排除超时类偶发。

这里有个反直觉的点：无痕模式不是"纯净环境"。部分浏览器在无痕下会禁用某些存储能力和扩展通讯接口，所以无痕下正常不等于线上就正常。我一般的顺序是先用无痕快速判断是不是缓存问题，如果不是，立刻退出无痕，改用"正常窗口 + 禁用扩展"再复现一次。

2. 排查工具链：从版本指纹到网络面板

2.1 第一步永远是版本指纹对比

我见过太多人跳过版本对比直接读代码。实际上浏览器兼容性冲突有一大半在版本对齐这一步就能定性。做法很简单：分别在两个浏览器的地址栏里查看版本信息，把关键字段抄到一张表里。下面是我这次记录的表格，字段是我自己习惯留的。

单靠肉眼对版本号还是太粗，我更喜欢在页面里塞一段指纹采集代码，把结果上报到日志，这样用户报障的时候我能直接看到他那边的真实环境，而不是靠他口述。

// 环境指纹采集，建议只在开发与灰度环境启用 function collectFingerprint() { const uaData = navigator.userAgentData; const brands = uaData?.brands?.map((b) => `${b.brand}/${b.version}`).join(', ') ?? 'n/a'; return { ua: navigator.userAgent, brands, // UA-CH 品牌列表 platform: uaData?.platform ?? navigator.platform, language: navigator.language, cores: navigator.hardwareConcurrency, memory: navigator.deviceMemory, dpr: window.devicePixelRatio, viewport: `${window.innerWidth}x${window.innerHeight}`, colorScheme: matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light', reducedMotion: matchMedia('(prefers-reduced-motion: reduce)').matches, hasStorageAccess: 'requestStorageAccess' in document, supportsHas: CSS.supports('selector(:has(*))'), supportsContainer: CSS.supports('container-type: inline-size'), tzOffset: new Date().getTimezoneOffset() }; }

这段代码的价值不在于信息多，而在于它把"猜"变成了"读"。比如我这次的弹窗问题，采集结果里brands显示同一个 Edge 设备上报了两种不同的品牌串，说明那台机器上的 Edge 版本已经被系统策略拉回了旧分支，而前端代码里正好有一段基于品牌串的分支逻辑，两边走的路不一样，问题就出在这里。

2.2 DevTools 的三板斧怎么用才有用

Network、Console、Application 这三个面板人人都会开，但用法差别很大。先说 Network：我必开的三项是 Preserve log（保留跨页日志）、Disable cache（禁用缓存，仅在调试期）、以及 Size / Time 两列排序。我见过一个很典型的错误是"接口 200 但页面还是白屏"，打开 Response 一看返回的是一段 HTML 登录页——这是登录态失效被网关重定向了，状态码骗了你，内容没骗你。所以我养成一个习惯：不看状态码，直接看响应体前 200 个字符。

再说 Console。Console 的用法只有一条铁律：看第一条错误，不是最后一条。页面上一个未捕获的异常会像多米诺骨牌一样引发后面十几条连锁报错，最后一条通常是"某个模块 undefined"，毫无信息量，第一条才是真凶。如果第一条报错信息太长看不全，展开 Call Stack，找到第一个非框架、非 vendor 的堆栈帧，那才是你要读的代码。

Application 面板我用得最多的是 Storage 里的 Cookie 和 Local Storage，以及 Service Workers 的注册记录。有一次线上问题是"用户退出登录后重新登录，权限还是旧的"，最后定位到 Service Worker 缓存的接口响应没清掉，用的是旧权限数据。Service Worker 这个东西一旦注册成功，你按 Ctrl+F5 是清不掉的，必须在 Application 里手动 Unregister，或者在代码里做版本号替换。

2.3 特性探测优于 UA 探测

浏览器兼容性冲突里，最古老也最顽固的一类错误是 UA 判断。早年大家用navigator.userAgent.indexOf('Chrome')来分浏览器，现在这条路已经彻底堵死了：UA 字符串被大幅精简，各家的品牌串相互包含，很多浏览器为了兼容老站点会同时声明多个品牌，你根本无法从字符串里可靠地分辨出"我到底在哪个浏览器里"。

正确的做法是全部换成能力探测，代码会更好读，也更稳：

// 不要这样写 const isEdge = /Edg\//.test(navigator.userAgent); // 应该这样写 const features = { storageAccess: 'requestStorageAccess' in document, inert: 'inert' in HTMLElement.prototype, structuredClone: typeof structuredClone === 'function', popover: 'showPopover' in HTMLElement.prototype, cssHas: CSS.supports('selector(:has(*))'), subgrid: CSS.supports('grid-template-columns: subgrid') }; // 然后按能力决定走哪条分支 if (!features.storageAccess) { // 走降级登录方案：整页跳转，不依赖嵌入式存储 location.assign('/login?mode=redirect'); }

这套写法有个额外好处：你不需要维护一张"哪个浏览器哪个版本支持什么"的表格，浏览器会自己告诉你答案。我在项目里把features对象挂在全局并上报，几次线上问题都是靠这个对象一眼定位的。

3. 三类高频冲突点的原理拆解

3.1 存储与登录态：第三方 Cookie 策略差异

这一次最折腾我的就是这块。我们的系统有一个嵌入式模块，被第三方站点用 iframe 嵌入，登录态依赖 Cookie。Chrome 上正常，Edge 上 iframe 里始终是未登录状态。原因在于两家对第三方 Cookie 的分阶段策略开关不完全一致，加上 Edge 的跟踪防护默认等级更严，嵌入侧的 Cookie 被当作跟踪标识拦掉了。

解决路径是走存储访问能力申请。这个接口的语义是：页面在跨站环境中主动向用户申请存储访问权限，用户同意后才允许读写独立的存储空间。代码大概长这样：

async function ensureCrossSiteStorage() { // 能力不存在，直接走降级 if (typeof document.hasStorageAccess !== 'function') { return { ok: false, reason: 'unsupported' }; } // 已经有访问权，直接返回 if (await document.hasStorageAccess()) { return { ok: true, reason: 'granted' }; } try { await document.requestStorageAccess(); return { ok: true, reason: 'just-granted' }; } catch (err) { // 用户拒绝、非用户手势触发、或策略拦截都会走到这里 return { ok: false, reason: err.name }; } } // 注意：必须在真实用户手势（click 等）的调用栈里触发，否则会被静默拒绝 document.getElementById('login-btn').addEventListener('click', async () => { const res = await ensureCrossSiteStorage(); if (!res.ok) { location.assign('/login?mode=redirect'); // 降级到整页跳转 } });

注意：这类接口必须在用户手势（click、touchend）的同步调用栈里发起，放在setTimeout里、Promise 深层回调里、或者页面加载时自动调用，基本都会被拒。我第一次写的时候放在onload里，两个浏览器都失败，还以为是兼容性问题，其实是调用时机问题。

除了存储权限，Cookie 本身的属性也要补齐。SameSite=None必须搭配Secure，Partitioned属性可以用来声明分区存储，HttpOnly该加就加。这几项不是可选项，缺一个就可能在某一家浏览器上被静默丢弃。

3.2 安全策略拦截：混合内容与私有网络访问

第二个白屏问题最终查出来是安全策略拦截。现象是请求挂了很久没响应，DevTools 的 Network 面板里那条请求状态显示为 blocked，Console 里有一行提示，大意是页面处于安全上下文，但请求指向了不太安全的地址，被策略拦下了。

这类拦截有两个常见来源。一个是混合内容，HTTPS 页面里引用了 HTTP 资源，浏览器会直接拦掉或者自动升级，行为在各家的默认值上不完全同步。另一个是私有网络访问限制，页面从公网地址发起请求到内网地址或本机地址时，会先发一个预检请求，要求服务端明确声明允许这种跨网络边界的访问，没声明就被拦。这个机制在两家的落地节奏上是有先后的，所以会出现"Chrome 能通、Edge 不通"或者反过来的情况。

前端侧的应对是在页面头部声明自动升级，把历史遗留的 HTTP 资源全部升级到 HTTPS：

<!-- 放在 head 最前面，尽量早于其他资源标签 --> <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

服务端侧的应对是补齐预检响应头，让跨网络边界的请求能正常通过：

# 允许私有网络预检通过 add_header Access-Control-Allow-Private-Network "true" always; # 明确允许的来源，别用通配 add_header Access-Control-Allow-Origin "https://example.internal" always; add_header Access-Control-Allow-Credentials "true" always; add_header Vary "Origin" always;

提示：排查这类拦截，最快的办法是打开 Network 面板，把过滤条件切到 "Blocked requests"，被安全策略拦下的请求会集中出现在这里，一眼就能看到，比在几十条请求里翻找快得多。

这里还有一个坑要提醒：跨域携带凭证时，Access-Control-Allow-Origin不能是通配符*，必须是具体来源。这个限制两家都是硬性的，不会放过。我见过有人为了省事写*，然后抱怨"开启了凭证模式反而全部跨域失败"，就是因为踩了这条。

3.3 扩展注入与内置功能的相互干扰

第三个 PDF 乱码的问题，最后发现根本不是我们的代码问题，而是浏览器内置的 PDF 阅读组件在渲染时用了系统字体集合，而 Edge 所在的机器缺少我们依赖的那套中文字体，所以落到默认字体上全是方块。但排查过程中我先怀疑的是扩展。

扩展干扰的表现特别像"浏览器兼容性问题"，因为它具有极强的个体性：同一台机器上装了某个阅读辅助扩展、某个划词翻译扩展、某个样式注入扩展，它们会往每个页面里塞 content script、塞样式表、塞键盘事件监听。典型症状包括：按钮点击被扩展的事件拦截，页面某个区域被样式覆盖导致布局错位，接口请求被扩展的拦截规则干掉导致页面永远停在 loading。你这边排半天代码，最后发现是用户装了个东西。

排查方法很直接：分别打开两个浏览器的扩展管理页，把两边扩展列表截图对比，再逐个禁用来定位。禁用扩展之后问题消失，就沿着扩展列表一路二分，通常三步之内就能锁定。这里我个人的经验是，优先怀疑三类扩展：样式注入类、脚本注入类、请求拦截类，因为它们直接参与了渲染或网络链路。

还有一个方向是浏览器内置功能。比如我们的 Vue3 页面在 Edge 里出现了右上角窗口按钮区域被遮挡、最小化按钮点不动的情况，根因是页面用了窗口控件覆盖的布局方案，而这个方案在两家的实现细节上有差异，导致标题栏区域的事件命中判定不同。这类问题的修法不是去追浏览器差异，而是把自定义标题栏的拖拽区域收窄，把保留给系统按钮的区域让出来，做一个安全边距，两边都能正常点。

3.4 渲染与视觉层的差异

渲染层的差异最容易被当成玄学，其实有三条很实在的来源。第一条是字体回退链。你声明的字体在某台机器上不存在，浏览器会按自己的顺序回退，不同浏览器的默认字体优先级不同，加上各系统自带的中文字体集合不同，就出现了同一段文字在两边排版不一致，甚至在 Canvas 绘制和 PDF 渲染时直接缺字。第二条是色彩与合成差异。GPU 驱动、色彩管理配置、HDR 支持都会影响画面，我遇到过一次 Canvas 在一边正常、另一边整体偏亮的问题，最后定位到是 GPU 合成路径不同，改成软件渲染后就一致了。第三条是字体渲染与滚动条占位。滚动条的宽度策略不同，会导致同一个容器在两边算出不同的可用宽度，进而触发不同的响应式断点，页面表现完全不一样。

针对字体，我的做法是显式定义一套完整的回退链，并且在部署时用自托管字体，不依赖用户系统里恰好装了什么：

@font-face { font-family: "AppSans"; src: url("/fonts/app-sans-subset.woff2") format("woff2"); font-display: swap; unicode-range: U+4E00-9FFF, U+3000-303F; /* 只覆盖中文与标点，控制体积 */ } body { font-family: "AppSans", "PingFang SC", "Microsoft YaHei", "Noto Sans CJK SC", sans-serif; }

针对布局宽度差异，我一般显式声明滚动条行为，让两边算出来的宽度一致：

.scroll-container { scrollbar-gutter: stable; /* 预留滚动条位置，避免宽度跳变 */ overflow-y: scroll; /* 强制常驻滚动槽，而不是按需出现 */ }

这两段看起来是小改动，但在我这次的项目里直接消灭了三个"时好时坏"的诡异现象。

4. 实操：一次完整修复过程

4.1 复现与埋点：把偶发变成必现

我这次的完整修复是从写一个复现脚本开始的，思路是不要靠手点，把操作路径自动化，跑一百遍，把偶发变成必现。同时加一层全局埋点，记录错误、版本、时间戳，让每一次失败都留下证据。

// 全局错误与性能埋点，仅在灰度环境启用 const trace = []; window.addEventListener('error', (e) => { trace.push({ type: 'error', message: e.message, source: `${e.filename}:${e.lineno}`, time: Math.round(performance.now()) }); }); window.addEventListener('unhandledrejection', (e) => { trace.push({ type: 'rejection', message: String(e.reason), time: Math.round(performance.now()) }); }); // 关键节点打点，定位卡在哪一步 performance.mark('app-bootstrap-start'); requestAnimationFrame(() => performance.mark('app-first-paint')); // 上报时把环境指纹一起带上 function report() { navigator.sendBeacon('/api/telemetry', JSON.stringify({ trace, env: collectFingerprint(), ts: Date.now() })); }

有一次偶发的白屏就是这么定位的：埋点显示错误发生在应用启动后 800 毫秒左右，错误信息指向一个异步加载的模块，而两边的差别是其中一边在启动阶段多了一个策略检查的往返请求，把加载顺序打乱了。没有埋点的话，这个问题我只能靠"再点一次看看"这种原始手段，基本不可能定位。

4.2 前端改造：从"猜浏览器"到"能力降级"

定位到根因之后，改造的核心思路只有一条：不判断浏览器，只判断能力，并且为每一种能力缺失准备一条完整的降级路径。我把项目里所有涉及判断的分支都收拢到一个适配层里，其他地方一律只调这个适配层，不允许业务代码里出现任何浏览器相关的字符串判断。

// capability.js —— 统一的适配层 export const caps = { crossSiteStorage: typeof document.hasStorageAccess === 'function', cssHas: CSS.supports('selector(:has(*))'), containerQuery: CSS.supports('container-type: inline-size'), inert: 'inert' in HTMLElement.prototype }; export async function withStorage(fn, fallback) { if (!caps.crossSiteStorage) return fallback(); try { return await fn(); } catch (err) { console.warn('[storage] fallback due to:', err.name); return fallback(); } }

CSS 侧同理，用@supports把新语法包起来，老环境走一份更保守的样式，而不是让整个页面崩掉：

/* 新语法：能力具备时生效 */ @supports selector(:has(*)) { .list-item:has(.badge-warning) { border-left: 3px solid #d97706; } } /* 保底写法：任何环境都能跑 */ .list-item.is-warning { border-left: 3px solid #d97706; }

这里我要强调一个反常识的经验：降级路径不是可有可无的兜底，它必须和主路径一样被完整测试。我这次上线后第二天就出了问题，原因就是降级路径从来没人在真机测过，里面有一个变量名写错了都没暴露。后面我在回归清单里强制加了一条：每个能力分支至少在一台对应环境的设备上跑一遍主流程。

4.3 工程侧的版本约定与构建配置

光改代码不够，还得在工程层面把版本约定固化下来。我们的做法是在项目根目录放一份浏览器支持清单，把最低支持基线和目标转换等级写死，构建工具会按这个清单去做语法降级。

# .browserslistrc [production] Chrome >= 109 Edge >= 109 Firefox >= 110 Safari >= 15.4 [development] last 2 versions

选 109 这个基线是有原因的：它是一个被大量存量设备长期停留的版本，很多老旧机器和受管设备都会停在这一档。把基线定低了，编译产物会变大、语法被压得更保守；定高了，线上就会有一批用户直接白屏。这个数字没有标准答案，要看你的实际用户分布，我的建议是从日志里拉一份真实版本分布，取覆盖 95% 用户的那个版本作为基线，而不是凭感觉写一个。

// 构建配置里显式指定目标，避免默认值带来的意外降级 // vite.config.js export default { build: { target: ['chrome109', 'edge109', 'firefox110', 'safari15.4'], cssTarget: ['chrome109', 'edge109'], sourcemap: true // 线上排查必开，但只在内网可见 } };

4.4 部署与缓存：让两边拿到同一份产物

最后一步经常被忽略：即使代码完全正确，如果两个浏览器拿到的产物不一致，还会出现"这边好了那边没好"。我这次就遇到了——一台机器上残留了旧版本的 Service Worker，新代码根本没生效。处理方式是把静态资源的缓存策略和 Service Worker 的版本管理都管起来。

# 带指纹的静态资源，长缓存 location ~* \.(js|css|woff2|png)$ { add_header Cache-Control "public, max-age=31536000, immutable" always; } # 入口 HTML，绝不缓存 location = /index.html { add_header Cache-Control "no-cache, must-revalidate" always; } # Service Worker 文件，绝不缓存，否则版本永远更新不了 location = /sw.js { add_header Cache-Control "no-cache" always; }

Service Worker 的更新逻辑我改成了主动版本检查，不再依赖浏览器的默认更新周期：

// 主动检查并升级 Service Worker if ('serviceWorker' in navigator) { navigator.serviceWorker.register('/sw.js').then((reg) => { // 每次页面可见时检查一次更新 document.addEventListener('visibilitychange', () => { if (document.visibilityState === 'visible') reg.update(); }); }); // 新版本接管后提示用户刷新，而不是静默替换 navigator.serviceWorker.addEventListener('controllerchange', () => { console.info('[sw] controller changed, reload recommended'); }); }

注意：Service Worker 的坑在于它可能长期驻留。排查阶段的固定动作是打开 Application 面板，看 Service Workers 那一栏有没有注册记录，有的话先 Unregister 再勾选 "Bypass for network" 重测，否则你所有的调试都可能跑在旧的缓存逻辑上。

5. 常见问题速查与踩坑总结

5.1 症状、根因、处理速查表

下面这张表是我自己攒的，按症状查就行，覆盖了这次和以往踩过的绝大多数场景。

5.2 我这次踩过的几个坑

第一个坑是用无痕模式得出结论。我在无痕下测出问题不存在，就判断是缓存问题，去清了缓存，结果线上照旧。真正的原因是那个环境在无痕下禁用了跨站存储能力，于是代码走了降级路径，恰好绕过了故障点。教训是：无痕只能用来做初步判断，不能作为结论。

第二个坑是只升级一边。为了对照，我把 Edge 升到了最新版，Chrome 保持旧版，然后得出"新版没问题"的结论。实际上版本对齐是双向的，你只要动了一边，对照实验就失效了。后来我改成两边都锁定同一个上游基线版本再测，结论才可靠。

第三个坑是只看最后一条报错。这次白屏问题在 Console 里刷了二十多条错误，我从最后一条开始读，花了半小时在无关模块里绕圈。从第一条读，五分钟就锁定了真凶，是启动阶段一次策略检查失败引发的连锁反应。

第四个坑是在业务代码里堆浏览器判断。项目里原本有三处按品牌串分支的逻辑，散落在不同文件里，这次排查一度以为是它们的问题。改造之后我把所有判断收拢进适配层，并加了一条代码规范：业务代码里出现浏览器名称字符串，代码评审直接打回。

第五个坑是忽略了排查工具本身的影响。开着 DevTools 的时候，某些面板会改变浏览器行为，比如禁用缓存、限制网络、甚至影响渲染路径。所以我给自己定了规矩：定位阶段随便开，验证阶段必须关掉 DevTools 再复测一次，两边都过才算修好。

5.3 日常巡检与维护清单

问题修完不算完，得想办法让它不再复发。我在项目里加了一份轻量的日常巡检清单，每周跑一次，成本不高但很有效。第一项是版本分布巡检，从日志里拉出用户的浏览器版本分布，看有没有异常集中的旧版本需要纳入基线。第二项是构建产物巡检，检查browserslist和构建目标有没有被无意改动。第三项是缓存与 Service Worker 巡检，确认缓存头和 SW 版本管理逻辑没有被改动。第四项是埋点健康度巡检，看错误上报里有没有新出现的错误类型或者突增的异常聚类。

这里还有一个我个人的小习惯，分享出来可能省你很多时间：我会在项目的 README 里维护一份"环境对照表"，把每次排查中确认过的版本组合、扩展组合、异常现象记进去。时间久了这份表就成了团队内部的排障手册，新人遇到类似问题可以直接查，不用每次都从零开始怀疑代码。这次的三次故障排查记录我已经全部补进去了，包括那个一看就头疼的弹窗问题——它的最终原因其实特别朴素，就是品牌串分支走到了另一条代码路径上，而那条路径上有个变量名拼错了，从来没被真实执行过。排查了大半天，改了六行代码，教训倒是挺值钱：凡是只在自己电脑上验证过的代码路径，都当成没写过。