抓包与 XSS 防护

• DevTools Network/Frame 面板
• 帧类型（文本/二进制/控制帧）
• 抓包工具（Wireshark、Charles）与解密

WebSocket 帧的调试主要用 DevTools Network 面板的 WS 与 Frames 子标签：可查看每条消息（帧）的文本/二进制内容、发送时间、方向。Frames 面板显示帧类型（text、binary、ping、pong、close）与数据。深层次抓包用 Wireshark（需解密 TLS/WSS）或 Charles/whistle 代理（可配置 SSL 解密查看 WebSocket 帧）。工程实践：确认帧格式与频率、排查协议错误、分析握手与关闭。WSS 抓包需导入 CA 证书解密。Debug 时注意区分帧的掩码与真实数据。

WebSocket 调试用 DevTools Frames 面板查看帧内容，深层次用 Wireshark/Charles 抓包（需 TLS 解密）。工程价值是排查协议、时序与数据问题。

• bfcache 机制（前进/后退缓存页面）
• 失效原因（unload、监听器、WebSocket 等）
• DevTools 调试与工程价值

bfcache（往返缓存）让浏览器在前进/后退时直接从内存恢复页面，而不是重新加载，大幅提升导航速度。DevTools Application 面板可查看 bfcache 使用情况与失效原因（Test bfcache 按钮）。失效原因包括：未使用 pagehide 替代 unload、注册了 unload 监听器、使用了 WebSocket、IndexedDB 打开、cache-control: no-store、某些扩展。工程价值：调试 bfcache 失效，修复监听器与存储问题，提升往返导航性能。避免使用 unload，改用 pagehide/visibilitychange。

bfcache 是"前进/后退秒开"的机制，失效原因可被 DevTools 诊断。工程上避免 unload、限制连接，提升 bfcache 命中率以改善导航体验。

• 拦截器（请求/响应）
• 统一错误处理
• Token 刷新队列（401 时挂起并刷新）

请求层封装通常用拦截器：请求拦截器注入 token、设置公共头；响应拦截器统一处理错误（401 触发刷新、业务错误码提示）。Token 刷新队列：当并发请求因 token 过期返回 401 时，用"刷新队列"机制——第一个 401 触发刷新 token，其余 401 请求挂起（pending），刷新完成后重放挂起的请求，避免重复刷新。工程实践：单例刷新锁、Promise 队列、刷新失败则清 token 跳登录。统一错误处理：区分网络错误、HTTP 错误、业务错误，统一日志与提示。

拦截器封装是"统一处理 + 集中逻辑"。Token 刷新队列解决"并发 401 重复刷新"问题：用队列挂起其他请求，刷新后重放。这是大型应用的请求层工程核心。

• 指数退避重试
• 超时与取消（AbortController）
• 幂等性保障（重试安全）

请求重试策略：对可重试错误（网络错误、5xx、超时）用指数退避（首次失败后延迟递增，如 1s、2s、4s，加抖动），避免重试风暴。超时用 AbortController 设置超时，超时后 abort 并可按需重试。取消用于用户/路由切换时中止请求。幂等性保障：重试只对幂等请求（GET、PUT、DELETE）安全，POST 重试可能重复创建，需幂等键或仅对安全错误重试。工程实践：封装重试逻辑（最大次数、退避、可重试判断），配合 AbortController 超时与取消。取舍：重试提升可用性，但需防风暴与副作用。

重试策略核心是"指数退避 + 抖动 + 幂等性"。超时/取消用 AbortController。幂等性决定重试安全，非幂等请求需额外保障。工程上按需重试并控制次数。

• 请求去重（单飞）
• 竞态（race condition）处理
• 防抖节流

搜索/自动补全场景常见问题：用户快速输入产生并发请求，需去重与竞态控制。去重（单飞）：同一请求并发时只发一次，共享结果。竞态：后发请求可能先返回，需用请求序号（最新请求优先）或 AbortController 取消过期请求，避免旧结果覆盖新结果。防抖（debounce）：延迟输入停止后再请求，减少请求量；节流（throttle）：固定间隔请求。边界：防抖适合输入结束才请求，节流适合需要定期更新。工程实践：debounce 减少请求 + 请求序号/Abort 防竞态 + 单飞去重。取舍：防抖延迟响应，节流可能丢中间状态。

搜索场景的边界是"减少请求（防抖）+ 避免竞态（序号/取消）+ 去重（单飞）"。竞态用最新请求优先，防抖控制频率。三者结合保证结果正确且不浪费请求。

• GraphQL/tRPC 与 REST 的类型安全
• 缓存模型差异
• Apollo Client 归一化缓存

GraphQL 提供类型安全（schema 驱动）与按需查询（只取所需字段），tRPC 提供端到端类型安全（TypeScript 全栈），REST 则简单但需手动类型与按需。缓存上：REST 的 HTTP 缓存（URL 级）简单；GraphQL 的 POST 查询难以 HTTP 缓存，需 Apollo Client 的归一化缓存（normalized cache）——按实体 ID 归一化存储，更新某实体时所有引用它的查询自动更新，避免重复数据，实现客户端缓存。tRPC 一般配合服务端缓存或 SWR。取舍：类型安全与查询灵活性选 GraphQL/tRPC，缓存与简单选 REST。Apollo 归一化缓存提升 GraphQL 客户端缓存效率。

GraphQL/tRPC 强调类型安全与灵活性，REST 强调简单与 HTTP 缓存。GraphQL 的 HTTP 缓存难，用 Apollo 归一化缓存按实体 ID 管理，实现自动更新。取舍是类型安全/灵活 vs 缓存简单。

• 缓存键设计（queryKey）
• 失效策略（invalidate、refetch）
• 乐观更新（optimistic update）

TanStack Query/SWR 是数据请求状态管理库。缓存键设计：queryKey 唯一标识查询（如 ['user', userId]），键变化则视为不同数据。失效策略：invalidateQueries 使缓存失效并重新请求；refetch 主动刷新；SWR 的 mutate 手动更新。乐观更新：先更新 UI（乐观值），再发起请求，失败回滚。工程实践：设计稳定的缓存键（按资源+参数）、按需失效（列表/详情联动）、乐观更新提升交互感知。取舍：缓存减少请求，失效保证新鲜，乐观更新提升体验但需回滚处理。

Query 库的核心是"缓存键 + 失效 + 更新"。键设计决定缓存粒度，失效策略控制新鲜度，乐观更新提升感知性能。工程上按资源建模键、按需失效、谨慎乐观更新。

• AbortController 取消请求
• 组件卸载/路由切换时清理
• 内存泄漏与状态更新防护

路由切换或组件卸载时，未完成的请求可能导致：状态更新已卸载组件（React 警告）、结果被应用（竞态）、内存泄漏。用 AbortController：组件卸载时（useEffect cleanup）调用 controller.abort()，取消请求并清理。工程实践：在 effect 中创建 AbortController，cleanup 时 abort；请求回调检查 AbortError 并忽略。防内存泄漏：取消后不更新状态、清理监听器。竞态防护：abort 过期请求，只采用最新。工程价值：避免卸载后更新、浪费带宽、泄漏。

请求取消的工程价值是"卸载即清理"。AbortController 配合 effect cleanup 取消请求，避免状态更新、竞态与泄漏。是 React/Vue 组件数据请求的规范做法。

• 中间件/拦截器模式
• 可组合的横切关注点
• 请求管线设计

请求层中间件（Middleware）模式：把日志、鉴权、错误上报、重试等横切关注点封装为可组合的中间件，按顺序串联在请求管线上。每个中间件可处理请求/响应、决定是否继续、可中止。可组合设计：每个中间件职责单一（如 authMiddleware 注入 token、retryMiddleware 重试、logMiddleware 记录），可灵活组合与复用。工程价值：关注点分离、可测试、可扩展。实现：axios 拦截器、koa 式中间件、自定义管线。取舍：中间件增加复杂度，但提升可维护性。

中间件模式把请求管线的横切关注点解耦为可组合单元。鉴权、重试、日志、上报各自独立，按序组合，实现可复用与可测试。是请求层工程的架构基础。

• persisted query（持久化查询）
• query whitelisting（白名单）
• 安全与性能价值

GraphQL 持久化查询（persisted query）把查询的 hash 与查询内容预注册到服务端，客户端发送 hash 而非完整查询，服务端用 hash 查找并执行。query whitelisting（白名单）只允许注册过的查询执行，拒绝任意查询。安全价值：防止任意/恶意查询（DoS，如深层嵌套、过度查询）、限制攻击面；性能价值：减少请求体（发送 hash 而非大查询）、服务端可预编译与缓存查询。工程实践：构建时提取查询并注册，客户端发送 hash。取舍：白名单减少灵活性，但提升安全与性能。适合生产环境。

persisted query 用 hash 代替完整查询，whitelisting 限制可执行查询。安全（防恶意查询）与性能（小请求体、预编译）双价值。工程上线时注册查询。

• DoH 与 DoT 的传输方式
• 区别（端口、封装）
• 隐私与安全价值

DoH（DNS over HTTPS）把 DNS 查询封装在 HTTPS（443 端口）中，DoT（DNS over TLS）把 DNS 查询封装在 TLS（853 端口）中。两者都加密 DNS 查询，防止窃听与篡改。区别：DoH 走 HTTPS（与 HTTP 流量混合，更隐蔽、不易被防火墙针对），DoT 走专用端口 853（更明确但易被识别阻断）。工程价值：提升 DNS 隐私与安全（防 DNS 劫持、污染、窃听），与 ECH 配合实现全链路隐私。DoH 在浏览器中更常见（Chrome 支持），DoT 在系统/网络层更常见。取舍：DoH 兼容好、隐蔽；DoT 更单纯但易被阻断。

DoH/DoT 都加密 DNS。DoH 用 HTTPS 443 隐蔽，DoT 用 853 专用端口。工程价值是防窃听/篡改/劫持，与 ECH 配合提升隐私。

• dangerouslySetInnerHTML/v-html 的机制
• XSS 风险（不安全 HTML）
• 富文本/SSR 的安全处理

dangerouslySetInnerHTML（React）与 v-html（Vue）直接设置 HTML，绕过框架的转义，若内容含不可信数据则产生 XSS。它们默认会转义文本，但 HTML 注入不转义。工程取舍：富文本/SSR 需要渲染 HTML，但必须净化：用 DOMPurify 等 sanitize 库过滤不安全标签/属性；服务端渲染时在服务端净化再输出；用 CSP 与 Trusted Types 兜底。最佳实践：避免直接使用 dangerouslySetInnerHTML/v-html 渲染不可信内容；必须用时先消毒。工程价值：理解 XSS 风险，正确消毒。

dangerouslySetInnerHTML/v-html 绕过转义，直接渲染 HTML，是 XSS 高风险点。富文本/SSR 必须消毒（DOMPurify）+ CSP + Trusted Types。工程取舍是"能力 vs 安全"。

• Trusted Types 强制安全 DOM 类型
• require-trusted-types-for script 指令
• 防 DOM XSS 的机制

Trusted Types 是浏览器 API，要求 DOM API 的赋值（如 innerHTML、script.src）必须使用 Trusted Types 创建的对象（TrustedHTML/TrustedScript/TrustedScriptURL），否则抛错。CSP 的 require-trusted-types-for 'script' 指令强制开启，使得所有脚本相关 DOM 注入都必须经过 Trusted Types 策略，从根上阻止不可信字符串直接注入 DOM，有效防 DOM XSS。工程价值：强制安全边界，配合 createPolicy 定义哪些值可信。取舍：需改造现有代码（用 createPolicy 包装），但极大提升 XSS 防护。是现代前端安全的关键。

Trusted Types 把"DOM 注入"限定为必须经策略创建的可信类型。require-trusted-types-for script 强制启用，阻止字符串直接注入。它从机制上防 DOM XSS，但需改造代码。

• JSONP 机制与安全风险
• JSON Hijacking（JSON 劫持）
• 现代 CORS 替代

JSONP 通过 <script src> 加载跨域 JSON（以回调函数包裹），绕过 CORS 限制。历史漏洞：JSON Hijacking（JSON 劫持）——攻击者用 <script> 或表单加载跨域 JSON，通过覆盖全局函数/数组构造器窃取数据（如 JSON 数组被当作脚本执行读取）。JSONP 也面临 XSS（回调名注入）与信任问题。现代替代：CORS（服务端 Access-Control-Allow-Origin 白名单）+ 正确 Content-Type（application/json 配合 CORB 防止被 script 读取）；创作 API 返回 JSON 而非 JSONP。工程价值：弃用 JSONP，用 CORS + 安全头（Nosniff、CORP）防 JSON 劫持。

JSONP 是绕过 CORS 的旧方案，有 JSON Hijacking 与 XSS 风险。现代用 CORS + 正确 Content-Type/CORB 防劫持。工程上废弃 JSONP 改用 CORS。

• DOMPurify sanitize 配置
• hook（beforeSanitize/afterSanitize）
• 富文本安全处理

DOMPurify 用于净化 HTML，sanitize(dirty, config) 可配置允许的标签/属性（ALLOWED_TAGS、ALLOWED_ATTR、FORBID_TAGS 等）。hook 提供自定义处理：beforeSanitize（净化前处理）、afterSanitize（净化后处理）、uponSanitizeElement 等，用于扩展规则（如自定义标签清理、特定属性处理）。富文本编辑器应用：渲染前用 DOMPurify 净化用户内容，配置允许的样式/标签，用 hook 处理视频/链接等。工程价值：灵活的安全净化，防止 XSS。取舍：配置过宽增加风险，过窄影响功能。

DOMPurify 的 sanitize 配置允许标签白名单，hook 提供自定义扩展。富文本用白名单净化 + hook 定制，平衡功能与安全。是富文本 XSS 防御的核心。

• 不同上下文的编码规则
• HTML/属性/URL/JS/CSS 编码
• 防 XSS 的上下文匹配

XSS 防御要求按"输出上下文"选择正确的编码：HTML 上下文（实体编码 <、>、&）、属性上下文（引号与实体编码）、URL 上下文（URL 编码 + 协议白名单）、JavaScript 上下文（字符串转义）、CSS 上下文（编码）。不同上下文编码规则不同，用错编码仍可被绕过。工程价值：框架默认转义 HTML 上下文，但属性/JS/URL 等需开发者按上下文编码。现代框架（React/Vue）对文本节点自动转义，但属性值、href、style 等需注意。正确按上下文编码是防 XSS 的基础。

上下文相关编码是 XSS 防御的核心：编码必须匹配输出位置。HTML 实体、属性引号、JS 字符串、URL、CSS 各不同。用错上下文可被绕过，需按输出位置编码。

• 反射型、存储型、DOM 型 XSS
• 攻击向量与触发方式
• 防御差异

反射型 XSS：恶意脚本由服务端在响应中直接反射（如 URL 参数未编码回显），一次性触发，需诱导用户点击含恶意参数的链接。存储型 XSS：恶意脚本被存储到服务器（数据库），其他用户访问时加载，持久、危害大（如评论、论坛）。DOM 型 XSS：恶意脚本在客户端由 DOM 操作触发（如 innerHTML 拼接不可信数据），不经过服务端，纯前端风险。攻击向量：反射靠 URL 参数、存储靠用户输入持久化、DOM 靠 unsafe DOM 操作。防御：输出编码（反射/存储）、输入验证、DOM 安全操作（DOM 型）、CSP。

三类 XSS 按"触发路径"区分：反射（服务端回显）、存储（持久化）、DOM（客户端 DOM 操作）。防御重心不同：反射/存储靠服务端编码，DOM 靠前端安全 API。理解攻击向量是防御基础。

• CSP 指令（script-src、object-src、frame-ancestors）
• DPoP（Demonstrating Proof-of-Possession）
• 现代安全取舍

CSP 指令：script-src 限制脚本来源（防 XSS，用 nonce/hash/白名单），object-src 限制 plug-in 对象（应设为 'none' 防插件型 XSS），frame-ancestors 限制可嵌入本页的 iframe 来源（防点击劫持）。DPoP（RFC 9449）是"Proof-of-Possession"机制，通过绑定证明（DPoP 的 JWT）证明请求拥有某个密钥，防止 token 被重放/盗用，是现代 OAuth 安全增强。取舍：CSP 防注入/劫持，DPoP 防 token 盗用/重放。两者是现代前端安全的不同层面，组合使用。

CSP 指令控制资源加载与嵌入（XSS/点击劫持），DPoP 防 token 重放/盗用。script-src 控脚本、object-src 禁插件、frame-ancestors 防劫持。DPoP 强化 token 绑定。取舍是不同安全需求。

• CORP 限制资源被跨源嵌入
• COEP 要求资源声明
• 对 XSS/CSRF 的防护协作

CORP（Cross-Origin-Resource-Policy）声明资源是否允许被跨源嵌入，COEP（Cross-Origin-Embedder-Policy）要求页面加载的跨源资源声明 CORP 或 CORS。协作：COEP: require-corp 强制跨源资源声明 CORP，阻止未授权资源被嵌入，从而减少跨源注入（XSS 载体）与跨源读取（CSRF/数据泄露）。它限制第三方脚本/资源被本页加载，降低 XSS 供应链风险；限制跨源响应读取，辅助 CSRF 防护。工程上：部署 CORP 声明资源可嵌入性，COEP 强制约束，配合 CORS 与 SameSite 形成纵深防御。

CORP/COEP 从"资源嵌入"层面限制跨源，减少恶意脚本注入与数据泄露。与 CORS（读取）、SameSite（Cookie）配合，构成纵深防御。COEP 是跨域隔离的一部分。

• Markdown 渲染库的 XSS 风险
• 配置（禁用 HTML、链接协议）
• 安全渲染实践

Markdown 渲染库（marked、markdown-it）默认把 Markdown 转为 HTML，可能包含原始 HTML（如 <script>、<img onerror>）与危险链接（javascript:），产生 XSS。安全处理：配置禁用原始 HTML（html: false）、链接协议白名单（linkify 防 javascript:）、使用 DOMPurify 对渲染结果再消毒、自定义渲染规则。工程实践：渲染后 sanitize（DOMPurify），配置难禁止的 HTML 与危险协议。取舍：禁用 HTML 减少功能但更安全，开启需强消毒。AI 输出 Markdown 时应净化。

Markdown 渲染的 XSS 来自"原始 HTML 与危险链接"。安全实践是禁用 HTML + 协议白名单 + DOMPurify 消毒。AI 流式输出 Markdown 时尤其需净化。

• Prototype Pollution 原理
• 攻击链（对象合并污染原型）
• 前端 XSS 利用

Prototype Pollution（原型污染）是攻击者通过操作对象原型（__proto__、constructor.prototype）污染所有对象共享属性。常发生在不安全的对象合并/深拷贝（如 Object.assign、递归合并用户输入）中。前端攻击链：污染 Object.prototype 后，可影响后续代码逻辑（如覆盖属性、改变默认值），进而可能触发 XSS（如污染某个被渲染到 DOM 的属性值）、逻辑绕过、RCE（在库中）。防护：避免直接合并不可信输入、使用安全合并（白名单键）、冻结原型（Object.freeze）、在合并时过滤 __proto__/constructor。工程上审查第三方库的合并逻辑。

Prototype Pollution 通过污染原型影响全局对象，是前端攻击链的重要一环。它常由不安全合并触发，可导致 XSS 或逻辑绕过。防护是安全合并与过滤危险键。

• Server Push 废弃原因
• 103 Early Hints 替代
• 取舍

HTTP/2 Server Push 因无法感知浏览器缓存、无法撤回、带宽浪费等问题被废弃，Chrome 已移除。替代方案是 103 Early Hints 配合 preload：服务器在最终响应前发送 103 头，携带 <link rel="preload"> 提示，浏览器主动请求关键资源。取舍：Early Hints 让浏览器控制（能感知缓存、精确请求），避免重复推送与带宽浪费；Server Push 是服务器盲目推送。工程上：用 preload + Early Hints 优化关键资源加载，弃用 Server Push。价值：更精确、更省带宽、与缓存兼容。

Server Push 因"盲目推送、无法感知缓存"被弃，103 Early Hints 把决定权交还浏览器。取舍是"服务器控制 vs 浏览器控制"，Early Hints 更符合缓存与带宽管理。

• Trusted Types 与 CSP 指令
• 协同防 XSS
• 部署策略

Trusted Types 与 CSP 协同：CSP 的 require-trusted-types-for 'script' 启用 Trusted Types，强制 DOM 注入必须用 Trusted Types 策略；CSP 的 trusted-types 指令限制允许的策略名。两者结合：CSP 限制脚本来源（script-src nonce/hash）+ Trusted Types 限制 DOM 注入，形成双重防护。工程实践：先 report-only 灰度，再强制；用 createPolicy 定义可信策略；配合 DOMPurify。协同价值：CSP 防脚本注入，Trusted Types 防 DOM 注入，覆盖 XSS 不同向量。

CSP 与 Trusted Types 协同是"来源 + 注入"双重防线。CSP 控脚本来源与策略白名单，Trusted Types 强制 DOM 注入类型安全。部署用 report-only 逐渐收紧。

• DOMPurify 的净化机制
• Mutation XSS（mXSS）原理
• 对 sanitizer 的绕过

DOMPurify 通过解析 HTML 并移除危险节点/属性来净化。Mutation XSS（mXSS）利用浏览器 HTML 解析器的"非线性变换"：DOM 树在序列化再解析时结构可能改变（如 <noscript>、<math>、<svg> 嵌套、特殊字符），使原本安全的净化结果在后续解析时变成可执行脚本，从而绕过 sanitizer。mXSS 是 sanitizer 的经典绕过。风险：净化后的 HTML 在渲染/序列化时被重新解析，触发 XSS。防护：使用更新到最新版本的 DOMPurify（修复 mXSS 变体）、在受控上下文渲染、避免对净化结果二次解析。trim（textContent）与 Trusted Types 辅助。

mXSS 利用"解析-序列化-再解析"的不一致绕过 sanitizer。净化结果在后续解析时结构变化触发脚本。防护靠最新 sanitizer + 受控渲染 + 避免二次解析。

• OWASP DOM XSS 测试用例
• 审计清单
• 工程价值

OWASP 提供 DOM XSS 测试用例（DOM XSS test cases），覆盖各类 DOM 注入点（innerHTML、document.write、location、eval、setTimeout 等）与 payload，用于验证应用的 XSS 防护。前端审计清单工程价值：把测试用例纳入安全审计，扫描代码中的危险 DOM 操作与 sink，验证 sanitizer/编码是否正确；用自动化测试（如 jest + jsdom）跑 OWASP 用例；CSP 与 Trusted Types 覆盖。工程价值：系统性检测 DOM XSS、防止回归、提升安全基线。

OWASP DOM XSS 用例是"标准化的 DOM XSS 验证集"。工程上纳入审计清单，自动化扫描 sink 与跑用例，验证防护有效并防回归。是安全工程的基础资产。

• Network 面板瀑布流
• 关键阶段（排队、DNS、连接、TTFB、下载）
• 性能分析

DevTools Network 面板的瀑布流显示每个请求的时间轴，分解为各阶段：Queuing（排队）、DNS（解析）、Connecting（连接/TLS）、TTFB（等待首字节）、Content Download（下载）。分析工程价值：识别瓶颈——长 TTFB（服务器慢）、长排队（连接数限制）、长压缩/下载（资源大）、未用缓存（重复请求）。可排序、筛选、查看 Initiator 与优先级。瀑布流分析定位性能瓶颈，指导优化（CDN、缓存、压缩、preload）。

瀑布流揭示请求的各阶段耗时。TTFB 长是服务器/网络问题，排队长是连接限制，下载长是资源大。工程上用瀑布流定位并优化瓶颈。这是性能调试的基础。

• HTTPS 抓包原理（中间人）
• CA 证书信任
• Wireshark SSL 密钥日志

HTTPS 流量加密，抓包需"中间人"解密：代理（Charles/whistle）生成自己的 CA 证书，安装到客户端信任链，客户端与代理的 TLS 连接用代理证书，代理再与服务器建立连接（MITM），从而解密查看明文。Wireshark 抓网络包需配置 SSLKEYLOGFILE 或导入预主密钥日志解密。原理：CA 证书让客户端信任代理，代理解密后转发。工程价值：调试 HTTPS 请求、查看加密内容、排查问题。风险：MITM 需用户信任证书，仅限调试环境。工程上 Charles/whistle 用本地 CA，Wireshark 用密钥日志。

HTTPS 抓包本质是 MITM：代理用自签 CA 让客户端信任，解密后转发。Wireshark 靠 SSLKEYLOGFILE 解密。工程价值是调试，需在本机信任 CA。

• Alt-Svc 头（Alternative Services）
• Alt-Used 头
• 协议升级（HTTP/2→HTTP/3）

HTTP Alt-Svc（Alternative Services）响应头让服务器声明可用的替代服务/协议（如 h3=":443" 表示支持 HTTP/3），客户端发现后可尝试用替代协议连接。Alt-Used 请求头表示客户端实际使用的替代服务。工程价值：服务发现与协议升级——客户端通过 Alt-Svc 发现 HTTP/3 支持，升级到更快协议；也用于负载均衡/服务迁移。应用：启用 HTTP/3 时，服务器返回 Alt-Svc 声明 h3，客户端下次用 HTTP/3。取舍：Alt-Svc 是提示性，客户端按需切换；需服务端支持。

Alt-Svc 让服务器声明替代服务/协议，客户端据此升级（如到 HTTP/3）。Alt-Used 回传实际使用。它是 HTTP/3 升级与服务发现的关键机制。

• 网络节流预设
• 自定义带宽/延迟
• 复现弱网场景

DevTools Network 面板的 Throttling 可设置网络状态：预设（Fast 3G、Slow 3G、Offline）或自定义（带宽、延迟、丢包）。工程价值：复现弱网/慢速网络场景，测试加载性能、超时、重试、降级逻辑。自定义设置可模拟特定带宽与延迟（如 2G、特定地区的延迟）。复现步骤：设 Offline 测离线、Slow 3G 测加载、自定义延迟测超时。通过节流复现真实弱网，验证性能与健壮性。

Throttling 让开发者本地模拟弱网。预设+自定义带宽/延迟/丢包，复现超时、重试、降级。工程价值是提前发现弱网问题。

• HAR 文件格式
• 导出与导入
• 跨环境对比分析

HAR（HTTP Archive）文件记录请求/响应完整信息（URL、头、时间、瀑布流各阶段），可从 DevTools 导出。工程价值：导出 HAR 用于跨环境对比（本地/测试/生产、不同设备/网络），分析性能差异、定位问题（如某环境 TTFB 长、缓存配置差异）。跨环境对比：用 HAR 工具（如 harviewer、在线分析）对比瀑布流、请求头、缓存命中。工程实践：导出 HAR 供协作/分析，对比环境差异定位性能与配置问题。注意 HAR 含敏感信息（Cookie、Body），分享需脱敏。

HAR 是请求的完整快照，用于跨环境对比与问题定位。工程价值是标准化分析性能与网络差异。导出分享需注意敏感信息脱敏。

• TCP Fast Open（TFO）原理
• 减少握手 RTT
• 服务端支持与限制

TCP Fast Open（TFO）允许在 TCP 三次握手的同时发送数据，减少一个 RTT。首次连接时客户端获取 TFO Cookie，后续连接在 SYN 中携带 Cookie 与数据，服务端验证后直接处理，无需等待握手完成。工程价值：减少建连 RTT（尤其 HTTPS/HTTP 场景），提升连接建立速度。服务端需支持 TFO（Linux 内核配置 tcp_fastopen）。限制：TFO Cookie 需首次获取、中间设备可能干扰、安全考虑（重放）。与 TLS 1.3 0-RTT、QUIC 结合进一步减 RTT。服务端启用后，客户端自动使用。

TFO 通过"SYN 携带数据"减少握手 RTT。服务端需内核支持。它是减 RTT 的手段之一，与 TLS 1.3 0-RTT、QUIC 协同。工程价值是连接建立加速。

• CDN 节点故障表现
• 诊断工具（dig、curl、ping、在线工具）
• 故障定位与回源

CDN 节点故障诊断：1) 用 dig/nslookup 查看解析到的节点 IP；2) 用 curl -I 多节点请求对比（不同地区/工具）；3) 用 ping/traceroute 检查网络连通与路由；4) 用 CDN 厂商状态页与在线测速工具（如 Cloudflare 状态、国际测速）；5) 对比 CDN 直接访问 vs 指定源站 IP（绕过 CDN 判断问题在 CDN 还是源站）。诊断步骤：确认是否全地区故障还是单节点、检查缓存/回源、查看日志（Upload/Origin 状态）。工程价值：快速定位故障（CDN 网络、节点、源站、配置），采取回退/屏蔽节点。

CDN 故障诊断是"分层排查"：DNS 解析、节点连通、回源、配置。用 dig/curl/ping/对比源站判断故障层。工程价值是快速定位与降级。

• pcap 抓包
• Wireshark 分析
• 端到端网络问题定位

pcap 是网络抓包格式，Wireshark 是主流分析工具，可抓取并分析网络层的 TCP/UDP/TLS/HTTP 等。工程价值：端到端网络调试——定位丢包、重传、RTT、握手失败、TLS 问题、DNS 问题。Wireshark 可过滤（tcp.flags、tls.handshake）、追踪 TCP 流、分析重传/乱序、查看 TLS 握手。应用场景：排查连接慢、超时、丢包、协议错误。配合 HTTPS 需解密（SSLKEYLOGFILE）。工程价值：深入网络层，是浏览器层工具无法覆盖的底层分析。

Wireshark 提供网络层深度分析（重传、丢包、握手、TLS）。工程价值是定位底层网络问题，补充 DevTools 的上层视角。需解密才能看 HTTPS 内容。

• net-export 抓取网络日志
• netlog 分析
• 生产环境问题定位

chrome://net-export 可导出 Chrome 的网络日志（netlog），chrome://net-internals 查看实时网络事件。netlog 记录请求、连接、DNS、代理、TLS 等底层事件，导出 JSON 后可用 netlog-viewer 分析。工程价值：生产/用户环境网络问题定位——连接失败、代理、DNS、证书、TLS 握手、请求被阻断等。用户提供 netlog 可异地复现分析。工程实践：让用户用 net-export 抓取，导出上传，用 netlog-viewer 分析事件流。价值：诊断浏览器层网络细节。

netlog 是浏览器网络层的详细日志，可导出分析。工程价值是定位生产环境的浏览器网络问题（DNS、代理、TLS、连接）。需用户抓取导出。

• 各代理工具的特点
• HTTPS 解密（CA 证书）
• 平台与功能取舍

whistle、Charles、Proxyman 都是本地 HTTP 代理，支持 HTTPS 解密（安装 CA 证书实现 MITM）。取舍：whistle（开源、跨平台、规则强大、支持 mock/rewrite/重放，适合规则驱动）；Charles（老牌、功能全面、UI 友好、Map Local/Remote、重放，但收费）；Proxyman（macOS 优化、现代 UI、性能好、支持 iOS 模拟器）。共同点：HTTPS 解密需安装 CA 证书、支持断点、抓包、mock。工程取舍：规则驱动选 whistle，跨平台全面选 Charles，macOS 优先选 Proxyman。三者都用于本地调试 HTTP 请求。

代理工具的核心是 HTTPS 解密与规则。whistle 规则强、Charles 全面、Proxyman 现代。取舍是平台、功能与规则能力。都需 CA 证书解密。

• Map Local（本地替换）
• Map Remote（远程重定向）
• SSR 联调与 mock

Charles 的 Map Local 把线上请求映射到本地文件（替换线上 JS/CSS/接口响应），Map Remote 把请求重定向到其他远程地址。工程价值：本地调试——用本地资源替换线上，快速验证改动（无需发布）；mock 接口（Map Local 返回本地 JSON）；SSR 联调——把某些请求映射到本地/测试环境，联调 SSR 渲染。工程实践：Map Local 替换静态资源与接口，Map Remote 切换环境（测试/生产）。取舍：Map Local 本地文件、Map Remote 远程转发，灵活模拟。价值：提升联调与调试效率。

Map Local/Remote 是"请求映射"工具。Local 替换本地、Remote 重定向远程，用于本地调试、mock 与环境切换。SSR 联调用远程映射。工程价值是无需改代码即可替换资源。

• QUIC 0-RTT/1-RTT 握手
• 弱网/CDN 兼容性
• 版本回落策略

QUIC 的 0-RTT 在恢复会话时省 RTT，提升弱网体验；但 0-RTT 有重放风险，且 CDN/移动网络存在兼容性踩坑：UDP 被防火墙/代理阻断、中间设备不支持 QUIC、0-RTT 数据被重放、NAT 超时。版本回落策略：检测 QUIC 不可用（连接失败、超时）时回落到 HTTP/2（TCP），保证可用性。工程实践：CDN 配置 QUIC 支持并监控；客户端/协议栈自动回退 HTTP/2；0-RTT 仅用于幂等请求。取舍：QUIC 提升弱网性能，但需兼容性兜底。工程价值：优先 QUIC，失败回退 HTTP/2。

QUIC 提升弱网但 UDP 可能被阻断，0-RTT 有重放风险。回落策略是"QUIC 失败回退 HTTP/2"。工程上配置 CDN 支持并监控，保证兼容。

• fetch priority 提示
• AbortSignal 嵌套
• 高并发调度

高并发场景下需控制请求优先级与调度：fetchpriority 属性（或 <link rel=preload fetchpriority>）提示浏览器关键资源优先级（high/low）；但 fetchpriority 是提示，实际由浏览器调度。AbortSignal 嵌套（AbortSignal.any()）组合多个取消源，实现统一取消（如组件卸载 + 超时）。调度策略：给关键请求高优先级，可取消低优先级请求；用 AbortSignal 管理取消。取舍：浏览器对优先级不完全受控，需合理设计。工程实践：关键资源/请求用 high priority，低价值请求可 postpone/取消，用 AbortSignal 组合取消。

请求优先级是"提示"而非强制。fetchpriority 标注关键请求，AbortSignal 组合取消，用于高并发调度与资源优先级控制。工程价值是合理分配带宽与取消。

• SVG 内嵌脚本风险
• CSS url() 注入
• 边界与防御

SVG 内嵌在 HTML 中可能携带脚本（<script>、<foreignObject>、事件属性），若 SVG 不可信则 XSS。CSS url() 注入：url() 可加载资源，若用户可控 CSS 值（如 background: url(javascript:...)）有风险。边界：SVG 需净化（DOMPurify 处理 SVG 命名空间）；CSS url() 需限制协议（白名单 http/https/data），禁止 javascript:。工程防御：SVG 用安全解析/净化、CSS 用属性白名单与协议校验、CSP 限制。工程价值：识别 SVG/CSS 的注入面，做好净化与协议限制。

SVG 与 CSS url() 是 XSS 攻击面。SVG 含脚本需净化，CSS url() 需协议白名单。工程上净化 SVG、限制 CSS 协议，配合 CSP。

• Service Worker 的 XSS 风险
• source map 泄漏源码
• 防护

Service Worker 若被 XSS 注入（如恶意脚本注册 SW），可拦截所有请求、篡改响应、窃取数据，危害极大。source map 泄漏：生产环境若暴露 .map 文件，可还原源码，泄露业务逻辑与密钥。防护：SW 脚本用 HTTPS + CSP 严格限制、SRI 校验、不执行不可信逻辑；source map 生产环境不发布（或仅内网/鉴权访问）。工程实践：生产 source map 关闭或访问控制；SW 注册 URL 与内容受控；CSP 防注入。工程价值：识别 SW 与 source map 的攻击面，防止供应链与源码泄露。

SW 被注入可全面接管请求，故需严格保护；source map 泄漏源码。工程上生产不发布 source map，SW 用 CSP/SRI 保护。两者都是供应链安全边界。

• mXSS 原理
• 绕过 sanitizer
• 防御

Mutation XSS（mXSS）利用浏览器 HTML 解析器的非线性变换：某些 HTML 在序列化再解析时结构改变（如 <math><mtext><style><img src=x onerror=...>），使 sanitizer 净化的结果在后续解析时变成可执行脚本。原理：净化器基于"解析-序列化"的假设，但浏览器解析器存在"突变"，导致净化结果被重新解析后形成 XSS。防御：使用最新 DOMPurify（修复 mXSS 变体）、避免对净化结果二次解析/序列化、在受控上下文渲染（textContent 而非 innerHTML）、Trusted Types 兜底。工程上持续更新 sanitizer 并测试 mXSS 用例。

mXSS 是 sanitizer 的经典绕过，源于解析器突变。防御靠最新 sanitizer、避免二次解析、受控渲染与 Trusted Types。需持续更新与测试。

• 各上下文的转义
• 安全上下文匹配
• 防 XSS

HTML 转义（如 <→<）只在 HTML 内容上下文正确。不同安全上下文需不同处理：HTML 上下文（实体编码）、Attribute 上下文（引号+实体）、JS 上下文（字符串转义）、URL 上下文（URL 编码+协议白名单）。用错上下文编码可被绕过。工程价值：框架默认转义 HTML 文本，但 attribute、href、JS 字符串需按上下文编码。安全上下文的核心是"编码规则匹配输出位置"。工程实践：按上下文选择编码，配合框架与 sanitizer。

转义必须匹配上下文。HTML 实体、属性引号、JS 字符串、URL 编码各不同。用错上下文是 XSS 常见成因。工程上按输出位置编码。

• CSP 指令（script-src、style-src、connect-src 等）
• 防 XSS 与注入
• 部署策略

CSP（Content Security Policy）通过响应头/<meta> 声明浏览器可加载的资源来源，限制脚本、样式、连接、图片等。核心指令：script-src（脚本来源）、style-src（样式）、connect-src（连接/API）、img-src、frame-ancestors（防点击劫持）、object-src。工程价值：防 XSS（限制脚本来源）、防注入、防数据外传。部署：用 nonce/hash 允许内联脚本，strict-dynamic，先用 report-only 灰度再强制。取舍：CSP 严格限制，需适配现有代码（内联/动态脚本）。现代 CSP Level 3 用 nonce/hash。

CSP 是"白名单式"资源控制，从源头限制脚本加载防 XSS。部署用 nonce/hash 处理内联、strict-dynamic 传递信任，report-only 渐进实施。是纵深防御核心。

• DOMPurify 钩子（beforeSanitize/afterSanitize 等）
• 自定义清理规则
• 工程扩展

DOMPurify 提供钩子（hooks）扩展清理规则：beforeSanitize（净化前）、afterSanitize（净化后）、uponSanitizeElement（每元素）、uponSanitizeAttribute（每属性）等。工程扩展：用钩子自定义标签/属性处理（如白名单外标签清理、特定属性校验、事件属性移除），或用钩子实现业务规则（如视频 iframe 白名单）。应用场景：富文本、Markdown 渲染、自定义组件。取舍：钩子灵活但需小心不破坏安全基座。工程价值：在 DOMPurify 默认净化基础上定制规则。

DOMPurify 钩子提供"净化流程的扩展点"。uponSanitizeElement/Attribute 可定制元素/属性处理，before/after 做前后处理。工程上扩展白名单与业务规则。

• URL 协议注入风险
• 协议白名单
• 防御实现

用户输入的 URL 若作为 href/src/跳转目标，可能注入危险协议（javascript:、data:），导致 XSS 或代码执行。防御：URL 协议白名单——只允许 http:、https:、mailto:、tel: 等安全协议，拒绝 javascript:、data:、vbscript:。工程实践：校验/净化用户 URL（解析协议、白名单匹配），前端渲染前限制，后端同样校验。配合 CSP 与 sanitizer。工程价值：防止 javascript: 注入的 XSS。注意统一编码绕过（javascript:）。

URL 协议白名单是"过滤危险协议"。javascript:/data: 可执行代码，需拒绝。工程上前后端都校验协议白名单，并防编码绕过。

• 模板注入原理
• SSR 框架风险
• 防御

模板注入（Template Injection）是攻击者把恶意模板表达式注入到模板引擎（如 Angular {{ }}、Vue {{ }}、服务端模板引擎），导致代码执行或数据泄露。SSR 框架若把用户输入直接拼入模板表达式或使用不安全模板，风险高。前端模板（Angular/Vue 插值）通常转义，但若用户输入被当作模板表达式计算（如动态编译、v-html/[innerHTML]），可触发表达式注入。防御：不要把用户输入当作模板表达式、不动态编译不可信模板、用插值/转义而非表达式执行、服务端模板引擎不执行用户输入。工程价值：识别模板注入面。

模板注入是"把用户输入当作模板表达式执行"。SSR 框架需避免把不可信输入作为模板表达式/动态编译。防御是"输入不当代码"边界。

• 第三方 iframe 的 XSS 风险
• sandbox 属性
• 隔离策略

第三方 iframe（广告、嵌入内容）若被 XSS 注入，可影响父页面。隔离策略：用 sandbox 属性限制 iframe 能力（无脚本、无同源访问、无弹窗等），即 <iframe sandbox="allow-scripts ...">；用 CSP 的 frame-src/frame-ancestors 限制；用 COEP/CORP 限制跨源资源；与父页面通过 postMessage 受控通信（不直接访问 DOM）。工程价值：第三方 iframe 沙箱隔离，限制其访问父页面权限，防 XSS 蔓延。取舍：sandbox 限制功能，需按需开放。

第三方 iframe 隔离用 sandbox 限制权限、CSP 限制来源、postMessage 受控通信。工程价值是隔离第三方内容，防 XSS 影响父页面。sandbox 是核心。

• createPolicy 创建策略
• 框架集成（Angular 默认启用、React 实验）
• 现代应用

Trusted Types 的 createPolicy 创建可信策略，定义允许的 DOM 注入（createHTML、createScript、createScriptURL）。框架集成：Angular 默认启用 Trusted Types（对 DomSanitizer 的返回值用 Trusted Types），React 有实验支持（react-dom 的 Trusted Types 集成交付官）。工程实践：框架用 createPolicy 包装 DOM 操作，富文本用 createHTML + DOMPurify，脚本用 createScript。现代应用：启用 createPolicy 后，所有 DOM 注入经策略，防 XSS。取舍：需改造框架配置，但安全提升大。

createPolicy 定义可信 DOM 注入来源。框架（Angular 默认、React 实验）集成 createPolicy，让框架管理 DOM 注入策略。工程价值是框架级 XSS 防护。

• WAF 与 CSP 的绕过
• 编码、混淆、突变
• 排查方法

XSS Payload 可绕过 WAF 与 CSP：通过编码（HTML 实体、URL 编码、Unicode）、混淆（大小写、注释、属性值切断）、事件容器（onerror、onfocus）、mutation（解析器突变）、CSP 绕过（unsafe-inline、jsonp、CDN 白名单滥用）。工程排查：审计输出点、测试编码/突变绕过、检查 CSP 配置（严不严格、有没有 unsafe-inline）、用 OWASP 用例测试。工程价值：识别 WAF/CSP 的绕过路径，加固防护。排查方法：Fuzz 测试、自动审计、CSP report-only 观察。

XSS 绕过是"编码/混淆/突变 + 防御配置漏洞"。排查需审计输出点、测试绕过、检查 CSP 严格性。工程价值是发现并加固绕过路径。

• 两者分工
• 协作防 XSS
• 现代应用

DOMPurify 负责净化 HTML 内容（移除危险标签/属性），Trusted Types 负责强制 DOM 注入类型安全（只允许策略创建的可信值）。协作：DOMPurify 作为 Trusted Types 策略的 createHTML 实现，净化后返回可信 HTML；Trusted Types 确保所有 DOM 注入都经过此净化。工程价值：双重防护——DOMPurify 净化内容，Trusted Types 强制注入路径。在富文本、AI 渲染等场景组合使用，实现纵深防御。工程实践：用 DOMPurify 实现 createPolicy，CSP 开启 require-trusted-types-for。

DOMPurify（内容净化）+ Trusted Types（类型强制）是现代 XSS 纵深防御。DOMPurify 做净化，Trusted Types 保证注入必经净化。工程价值是"内容 + 路径"双重防护。

• JSON Hijacking 原理
• JSONP/数组劫持
• 现代防御

JSON Hijacking（JSON 劫持）指攻击者通过 <script>、<object> 或 JSONP 加载跨域 JSON，利用 JSON 数组/对象被当作脚本解析或覆盖全局对象的方式窃取数据。现代防御：1) 用 CORS 而非 JSONP（跨源读取需显式允许）；2) 正确 Content-Type（application/json + X-Content-Type-Options: nosniff），配合 CORB 阻止被 script 加载；3) 前缀 )]}' 或加难解析的响应头（防 script 解析）；4) 认证 Cookie 用 HttpOnly + SameSite。工程价值：防止 JSONP/JSON 劫持窃取数据。现代弃用 JSONP，用 CORS + 安全头。

JSON Hijacking 靠浏览器把 JSON 当脚本解析/读取。现代防御是 CORS + 正确 Content-Type + nosniff/CORB + 安全 Cookie。弃用 JSONP 是根本。

• 危险 DOM API
• XSS 风险
• 现代替代（createElement、textContent、Trusted Types）

innerHTML、outerHTML、insertAdjacentHTML 会解析并插入 HTML 字符串，若内容不可信则 XSS。它们是 DOM 注入的 sink。现代替代：用 createElement + textContent（创建元素并设置文本，自动转义）、appendChild、setAttribute 安全设属性；textContent 不解析 HTML。若必须插入 HTML，用 sanitizer（DOMPurify）或 Trusted Types 策略。工程价值：避免直接 innerHTML 注入不可信数据。React/Vue 的 textContent 默认转义，dangerouslySetInnerHTML/v-html 需消毒。

innerHTML 等是"解析 HTML 的 sink"，XSS 风险高。替代是 createElement/textContent（不解析）或消毒+Trusted Types。工程上避免直接注入不可信 HTML。

• Trusted Types 浏览器支持
• DOMPurify 的 Trusted Types 支持
• 降级策略

Trusted Types 是 Chrome 等支持、Safari/Firefox 支持有限的新 API。不支持的环境下，require-trusted-types-for 指令不生效，需降级。DOMPurify 提供 Trusted Types 支持（可配置），并可作为 polyfill 的补充。工程降级：检测 trustedTypes 可用性，不可用时用 DOMPurify 净化兜底；CSP 的 require-trusted-types-for 在支持的浏览器生效。工程价值：渐进增强——支持浏览器用 Trusted Types，不支持用 DOMPurify 净化。取舍：需维护双路径，但覆盖不同浏览器。

Trusted Types 支持有限，需降级。DOMPurify 做净化兜底，检测 trustedTypes 可用性。工程上"支持则用，不支持则净化"，保证兼容与安全。

• SVG 内嵌脚本与事件
• XML 实体与外链
• 攻击向量与防御

SVG 是 XSS 攻击向量：SVG 可内嵌 <script>、<foreignObject> 嵌入 HTML、事件属性（onload）、<set>/<animate> 触发、<use> 引用外部资源。XML 解析：外部实体（XXE）、DOCTYPE、外部引用。攻击向量：SVG 作为图像/上传被解析执行脚本；XML 中恶意实体。防御：SVG 用安全解析（DOMPurify 处理 SVG 命名空间）、禁用脚本与危险元素；XML 禁用外部实体（XXE）、限制解析。工程价值：识别 SVG/XML 的注入面。上传 SVG 需严格净化。

SVG 可执行脚本（script/foreignObject/事件），XML 有 XXE 风险。防御是净化 SVG（禁脚本）、禁用 XML 外部实体。工程上对上传 SVG/XML 严格处理。

• 富文本编辑器的 XSS 风险
• 输出净化（DOMPurify）
• 现代编辑器的安全方案

富文本编辑器（Tiptap、Slate）输出 HTML，用户输入的富文本可能含危险标签/属性（script、onerror、javascript:），存储与渲染时 XSS。防御：编辑器配置白名单（允许的标签/属性）、输出时用 DOMPurify 净化、渲染时用安全方式（Trusted Types）、存储前净化。现代应用：Tiptap 基于 ProseMirror 用 schema 限制节点/属性（白名单），Slate 用自定义富文本结构（避免直接 HTML）。工程实践：编辑器 schema 白名单 + 后端/前端 DOMPurify 净化 + Trusted Types。工程价值：富文本安全渲染。

富文本 XSS 防御是"schema 白名单 + 输出净化 + 安全渲染"。Tiptap 用 schema 限制，Slate 用结构化数据。工程上净化输出并防存储注入。

• nonce-source（nonce）
• hash-source（sha256-）
• 现代构建产物（内联脚本）的取舍

CSP 的 script-src 'nonce-xxx' 允许带指定 nonce 的内联脚本，'sha256-xxx' 允许哈希匹配的内联脚本。nonce：每次响应生成随机 nonce，适用于动态内联脚本，但需服务端支持（每次刷新变化）；hash：内联脚本的哈希，静态、无需服务端随机，但脚本内容变化需更新哈希。现代构建产物（如 Webpack 生成的 runtime 内联脚本）通常用 hash 或 nonce。取舍：nonce 灵活（动态脚本）但需服务端生成；hash 稳定（固定脚本）但内容变需更新。工程上常 combined：nonce + strict-dynamic。现代 CSP Level 3 配合 strict-dynamic 传递信任。

nonce 用于动态内联脚本（需服务端），hash 用于静态内联脚本（无需服务端）。现代构建产物用 nonce/hash 允许内联，配合 strict-dynamic。取舍是动态 vs 静态、服务端支持。

• strict-dynamic 机制
• 信任传递
• 现代工程价值

CSP Level 3 的 strict-dynamic 让"被 nonce/hash 允许的脚本"动态加载的脚本也获得信任（信任传递），无需在 CSP 中列所有信任域名。它针对现代应用（模块化脚本动态加载）设计：nonce 脚本可以加载并信任其子脚本，无需通配符。工程价值：避免 script-src 通配域名扩大攻击面；配合 nonce/hash 实现安全动态加载；与 require-trusted-types-for 协同。取舍：strict-dynamic 需配合 nonce/hash，且旧浏览器（不支持）需白名单兜底。现代前端用 nonce + strict-dynamic 是 CSP 最佳实践。

strict-dynamic 让信任从 nonce/hash 脚本传递到其动态加载的脚本，避免通配域名。这是现代 CSP 的安全基线，配合 nonce/hash 与 Trusted Types。

• DOM Clobbering 原理
• id 属性污染全局变量
• 攻击与防御

DOM Clobbering（DOM 污染）是攻击者通过注入带 id/name 属性的 HTML 元素，覆盖同名全局变量（window 属性）或库依赖的全局对象，导致逻辑绕过或 XSS。例如注入 <form id="config"><input name="a"> 覆盖 window.config。攻击影响：覆盖安全判断、污染库的全局引用、绕过检查。防御：避免依赖全局变量做安全判断、用 Object.getOwnPropertyDescriptor 检查、window 属性使用 Object.defineProperty 保护、DOMPurify 阻止危险元素、CSP。工程价值：识别 DOM Clobbering 攻击面，审计全局变量使用。

DOM Clobbering 用 id/name 覆盖全局变量，是前端特有的攻击。防御是避免全局变量做安全判断、净化、保护全局属性。工程上审计全局引用。

• MutationObserver 机制
• 运行时 DOM 监控
• 检测恶意注入

MutationObserver 可监听 DOM 变化（节点添加/移除、属性变化），用于运行时监控。工程价值：检测 DOM 注入恶意内容——监控节点插入，若发现可疑元素（如 script、带 onerror 的 img）或外来注入，可告警/拦截。但注意：MutationObserver 是"事后"观察（DOM 已变化），无法完全阻止（脚本可能已执行），且 onerror 等在插入时已触发。它更适合检测与审计，而非阻断。工程价值：安全监控、行为审计、检测第三方脚本注入。配合 CSP/Trusted Types 做预防。

MutationObserver 监控 DOM 变化，用于检测恶意注入。但它是事后观察，无法阻止已执行的脚本。工程价值是监控与审计，预防靠 CSP/Trusted Types。

• SW 与 CSP 的关系
• unsafe-eval 与 eval
• PWA 字符串编译边界

Service Worker 的脚本受 CSP 约束（script-src 需允许 SW 脚本来源）。PWA 中若用字符串编译（eval、Function、new Function）执行代码，需 CSP 的 unsafe-eval，但会扩大 XSS 攻击面。边界：SW 中避免 eval 等字符串编译（CSP 禁 unsafe-eval 更安全）；若必须，用受限方式（如 JSON.parse、白名单映射）替代。工程价值：CSP 限制 eval 防 XSS；PWA 用安全替代字符串编译。取舍：unsafe-eval 便利但危险，应避免。SW 脚本自身用严格 CSP。

CSP 禁 unsafe-eval 可防 eval 型 XSS。SW/PWA 应避免字符串编译，用安全替代。取舍是便利 vs 安全，工程上规避 eval。

• eval 类动态执行
• CSP unsafe-eval 限制
• 安全替代方案

eval()、Function()、setTimeout("string") 都是字符串编译执行，CSP 的 unsafe-eval 禁用后这些 API 抛异常。替代方案：1) 用 setTimeout(fn, 0) 传函数而非字符串；2) 用 JSON.parse 解析数据而非执行代码；3) 用函数映射/配置驱动逻辑（白名单）；4) 用 new Function 前的替代（如 Module 编译、WebAssembly）；5) 用 import() 动态导入模块。工程价值：避免 eval，CSP 禁 unsafe-eval 提升安全。取舍：动态代码执行改为配置/导入，更安全。

unsafe-eval 禁用后，eval/Function/setTimeout(string) 失效。替代是传函数、JSON.parse、配置映射、动态 import。工程价值是去掉 eval 型执行，提升 CSP 安全。

• 模板引擎的转义
• XSS 风险
• 安全使用

模板引擎（Handlebars、EJS、Mustache）默认转义输出（{{var}} 转义 HTML），但 triple-stache（{{{var}}}）、<%- %>（EJS 原始输出）不转义，若内容是用户输入则 XSS。风险：原始输出输出点、模板注入、dangerous 子模板。安全使用：用默认转义输出、避免原始输出用于不可信数据、模板数据需净化、服务端模板引擎不执行用户输入。工程价值：理解模板引擎转义边界，正确使用。取舍：原始输出便利但需消毒。

模板引擎默认转义，但原始输出（{{{}}}、<%- %>）不转义是 XSS 点。安全使用是默认转义 + 原始输出消毒 + 不执行用户输入。

• Sanitizer API（setHTML）
• 浏览器原生净化
• 与 DOMPurify 对比

Sanitizer API（Element.setHTML）是浏览器原生净化 API，用 new Sanitizer() 配置后 el.setHTML(html) 净化并插入 HTML，无需第三方库。它由浏览器实现，与解析器一致，性能好、无第三方依赖。相比 DOMPurify：Sanitizer API 是原生、规范演进、性能好，但支持度有限（Chrome 支持，Safari/Firefox 待完善）；DOMPurify 成熟、跨浏览器、可定制。工程价值：原生净化减少依赖，作为渐进增强；DOMPurify 作兼容兜底。取舍：支持度与成熟度 vs 原生性能。

Sanitizer API 是浏览器原生净化，性能好但支持有限；DOMPurify 成熟跨浏览器。工程上"原生优先 + DOMPurify 兜底"。价值是减少依赖与性能。

• SVG script/foreignObject
• MathML 攻击面
• 防御

SVG 中的 <script> 可执行脚本，<foreignObject> 可嵌入 HTML（含 script），都是 XSS 载体。MathML（数学标记语言）也可用于 XSS（如 <math><mtext><style><img onerror>）构造 mXSS，或借助 MathML 的元素触发解析器突变。攻击面：SVG/MathML 的嵌套与解析器突变可绕过 sanitizer。防御：净化器禁用 SVG/MathML 的脚本与危险元素、用最新 sanitizer 处理命名空间、受限渲染。工程价值：识别 SVG/MathML 的 XSS 面，强化净化。

SVG script/foreignObject 与 MathML 是 XSS 与 mXSS 载体。防御是净化器禁用危险元素、处理命名空间、避免解析器突变。工程上严格净化 SVG/MathML。

• React Server Components 边界
• client 边界与 XSS
• 工程价值

React 19 的 Server Components 在服务端运行，数据不进入客户端 bundle。默认不暴露 client 边界：服务器组件返回的可序列化数据，客户端只接收序列化后的结果，不直接接收不可信对象/函数，减少将服务端数据直接注入 DOM 的 XSS 面。工程价值：服务端渲染的内容不经客户端执行，降低客户端 XSS 攻击面；数据边界更清晰。但需注意：server 组件返回的 HTML 仍可能含不安全内容（需净化），client 组件仍要防 XSS。取舍：Server Components 减少一种 XSS 面，但非万能。

Server Components 把渲染移到服务端，数据不直接进客户端 bundle，减少客户端 XSS 面。但服务端输出仍需净化。工程价值是边界的清晰与攻击面缩小。

• report-uri/report-to
• Report-Only 模式
• 渐进实施

CSP 的 report-uri/report-to 让浏览器上报违规事件，Content-Security-Policy-Report-Only 只上报不阻止（Report-Only 模式）。渐进实施策略：1) 先用 Report-Only 观察违规，收集真实违规；2) 根据报告调整策略（放宽或收紧）；3) 违规稳定后切换到强制执行；4) 持续监控报告。工程价值：在不破坏现有功能的前提下安全实施 CSP，避免强制后资源被阻断。report-to 是 Reporting API 的新端点，report-uri 是旧机制。工程上先 report-only 灰度再强制。

CSP 渐进实施是"先上报后强制"。Report-Only 收集违规，调整策略，再强制并持续监控。report-to（Reporting API）替代 report-uri。价值是安全部署。

• SSR 与 CSR 的 sanitizer 规则一致性
• 序列化与签名
• 防 hydration 不一致 XSS

SSR 场景下，服务端用 DOMPurify 净化内容，客户端 hydration 时若 client 端 sanitizer 与 server 端规则不一致，可能导致内容被 re-sanitize 或差分，产生 XSS 或 hydration 不匹配。关键：1) 规则一致性——server 和 client 用同一套 sanitize 配置（共享配置模块）；2) 序列化——把服务端净化后的 HTML 作为权威输出，hydrate 时不做二次净化（除非需要）；3) 签名——若需在客户端验证净化结果可信，可用签名（HMAC）标记服务端净化过的内容，客户端校验签名后信任（防止篡改）。4) 避免 client 端二次净化改变结构（mXSS）。工程实践：共享 sanitize 配置、服务端净化并签名、客户端校验签名信任。工程价值：保证 SSR→CSR 一致，防 hydration XSS。

SSR/CSR 的 sanitizer 不一致是 hydration XSS 的来源。解决是共享配置保持规则一致、服务端净化并签名、客户端校验签名信任权威结果。签名防篡改。

• policy 命名
• 命名空间与 CSP 限制
• 工程实践

Trusted Types 的 createPolicy(name, ...) 创建有名字的策略，CSP 的 trusted-types 指令限制允许的策略名（trusted-types 'default' 'app'）。命名用于控制：只有 CSP 白名单内的策略名可用，防止任意策略创建。命名空间工程实践：按用途命名（如 'default'、'app-html'、'app-script'），CSP 白名单限定，便于审计与最小权限。命名冲突：同源内不能重复创建同名策略（除非 default 策略）。工程价值：策略命名实现细粒度控制与审计。

policy 命名让 CSP 能白名单控制允许的策略。命名空间按用途划分，配合 CSP 的 trusted-types 指令实现最小权限。工程上命名清晰并审计。

• mXSS 的非线性变换
• React/Vue reconciliation 路径
• Trusted Types/DOMPurify 的 mXSS 面

mXSS 利用浏览器解析器的"innerHTML→序列化→再解析"非线性变换（如 <svg><style><img onerror> 结构突变）绕过 sanitizer。攻击面路径：React/Vue 的 reconciliation 若用 dangerouslySetInnerHTML/v-html 直接把净化后的 HTML 插入（不经过二次解析），mXSS 面较小；但若净化后内容被序列化再解析（如 innerHTML 读取再写入、框架 state 序列化），则触发 mXSS。DOMPurify 对已知 mXSS 变体有防护，但新变体（解析器更新）仍可能绕过；Trusted Types 只保证"注入经策略"，不保证"净化结果无误"（仍需 DOMPurify 正确）。工程上：避免对净化结果二次序列化/解析、用最新 DOMPurify、用 textContent 或受控 DOM 操作、Trusted Types 兜底注入路径。

mXSS 攻击面在"净化后内容被二次解析"的路径。React/Vue 直接插入净化 HTML 面小，二次序列化/解析面大。DOMPurify 需最新，Trusted Types 兜底注入但不解决净化正确性。

• nosniff 关闭 MIME 嗅探
• 阻断存储型 XSS 链路
• MIME 不匹配拦截与 Content-Type 标准

X-Content-Type-Options: nosniff 让浏览器不进行 MIME 嗅探，严格按响应 Content-Type 处理。它阻断存储型 XSS：若攻击者上传伪装成图片/文本的 HTML（Content-Type 为 image/png 或 text/plain），nosniff 下浏览器不会把它当 HTML/脚本执行，而是按声明类型处理（图片不解析、文本不执行脚本），阻断"上传 HTML 内容被当作脚本执行"的 XSS 链路。nosniff 对 script/style 的 MIME 不匹配：加载 <script> 时若 Content-Type 不是合法的 JS MIME（如 application/javascript），nosniff 下浏览器拒绝执行；<link rel=stylesheet> 若不是 CSS MIME 也拒绝。部署配套：为所有资源设置正确 Content-Type（HTML 用 text/html、JS 用 application/javascript、CSS 用 text/css、图片用 image/*），并启用 nosniff。工程价值：减少 MIME 混淆攻击，强化存储型 XSS 防护。

nosniff 关闭嗅探，强制按 Content-Type 处理，阻断伪装 HTML 被当脚本执行。对 script/style 的 MIME 不匹配会拦截。配套是正确设置 Content-Type 与 nosniff。