# 1. WebSocket 帧的抓包与调试 A DevTools Frames 面板可查看帧类型与内容，深层次抓包需 TLS 解密 ✓ 正确答案 B WebSocket 帧无法被抓包 C Wireshark 无需解密即可查看 WSS 内容 D Frames 面板只能查看握手
# 2. Chrome DevTools Back-forward Cache (bfcache) 调试与失效原因的工程价值 A DevTools 可诊断 bfcache 失效原因（如 unload 监听器、WebSocket），修复后提升导航性能 ✓ 正确答案 B bfcache 只影响前进，不影响后退 C bfcache 无法被调试 D unload 监听器不影响 bfcache
# 3. fetch/axios 封装，拦截器、统一错误处理与 Token 刷新队列（401 自动刷新与请求挂起） A 每个 401 都独立刷新 token B 拦截器与 token 刷新无关 C 401 时用单例刷新队列挂起并发请求，刷新后重放，避免重复刷新 ✓ 正确答案 D 401 应直接跳登录
# 4. 请求重试与指数退避、超时与取消（AbortController）策略设计与幂等性保障 A 所有请求都应无条件重试 B 用指数退避+抖动重试，且仅对幂等请求安全重试，非幂等需额外保障 ✓ 正确答案 C 重试不会造成副作用 D 超时与重试无关
# 5. 并发请求的去重、竞态（race condition）与防抖节流在搜索/自动补全场景的边界 A 用防抖减少请求、请求序号/Abort 防竞态，保证最新结果正确 ✓ 正确答案 B 竞态无需处理，后发结果自然正确 C 去重与竞态无关 D 节流会延迟响应但保证最新
# 6. GraphQL/tRPC 与 REST 在类型安全与缓存上的取舍及 Apollo Client 归一化缓存的工程价值 A GraphQL/tRPC 提供类型安全，Apollo 归一化缓存按实体 ID 管理，解决 GraphQL 客户端缓存 ✓ 正确答案 B GraphQL 的 HTTP 缓存比 REST 简单 C tRPC 无类型安全 D Apollo 缓存只用于 REST
# 7. TanStack Query/SWR 的缓存键设计、失效策略与乐观更新的工程实践 A 缓存键随意设计不影响正确性 B 失效策略与缓存无关 C 用稳定 queryKey 建模、invalidate 失效、乐观更新提升体验并回滚 ✓ 正确答案 D 乐观更新无需回滚
# 8. 请求取消（AbortController）在路由切换/组件卸载时的自动清理与内存泄漏防护 A 卸载后请求继续执行即可 B 组件卸载时用 AbortController 取消请求，避免状态更新与内存泄漏 ✓ 正确答案 C 请求取消与竞态无关 D AbortError 无需特殊处理
# 9. 请求层的中介者（Middleware）模式，日志、鉴权、错误上报与重试的可组合设计 A 中间件只能做一件事，无法组合 B 中间件会破坏关注点分离 C 中间件与拦截器完全不同 D 中间件把日志、鉴权、重试等横切关注点封装为可组合单元，按序串联 ✓ 正确答案
# 10. GraphQL 的 persisted query 与 query whitelisting 在生产环境的安全与性能价值 A persisted query 让客户端发送完整查询 B persisted query 用 hash 发送查询并预注册，whitelisting 限制可执行查询，提升安全与性能 ✓ 正确答案 C whitelisting 允许任意查询 D persisted query 与安全无关
# 11. DNS over HTTPS（DoH）与 DNS over TLS（DoT） A DoH 走 853 端口，DoT 走 443 B DoH 与隐私无关 C 两者都不加密 DNS D DoH 用 HTTPS 封装（隐蔽），DoT 用 TLS 专用端口，都加密 DNS 防劫持 ✓ 正确答案
# 12. React/Vue 的 dangerouslySetInnerHTML/v-html 在服务端渲染或富文本的 XSS 工程取舍 A dangerouslySetInnerHTML 会自动转义 HTML，无风险 B 它们直接渲染 HTML，不可信内容需先消毒（DOMPurify）并配合 CSP/Trusted Types ✓ 正确答案 C 富文本渲染无需消毒 D v-html 与 React 的 dangerouslySetInnerHTML 机制不同
# 13. Trusted Types（require-trusted-types-for script） A 它禁用所有 DOM 操作 B 它强制 DOM 注入必须用 Trusted Types 策略创建，从机制上防 DOM XSS ✓ 正确答案 C 它只影响服务端渲染 D 它无需 CSP 配合
# 14. JSONP 与 JSON Hijacking 的历史漏洞与现代 CORS 的替代 A JSONP 是现代安全的跨域方案 B JSONP 有 JSON Hijacking 与 XSS 风险，现代用 CORS + 正确 Content-Type/CORB 替代 ✓ 正确答案 C JSON Hijacking 与 JSONP 无关 D CORS 无法替代 JSONP
# 15. DOMPurify 的 hook 与 sanitize 配置在富文本编辑器的应用 A DOMPurify 只能净化，不能配置 B hook 无法扩展规则 C sanitize 配置白名单标签/属性，hook 提供自定义处理，用于富文本安全净化 ✓ 正确答案 D 富文本无需净化
# 16. 上下文相关输出编码（HTML、属性、URL、JavaScript、CSS） A 所有上下文用同一种编码即可 B 框架自动处理所有上下文编码 C 编码与 XSS 无关 D HTML、属性、URL、JS、CSS 上下文编码规则不同，必须按输出位置匹配 ✓ 正确答案
# 17. 反射型、存储型、DOM 型 XSS 的区别与攻击向量 A 反射型 XSS 会持久化存储 B DOM 型 XSS 经过服务端 C 反射型由服务端回显触发、存储型持久化、DOM 型在客户端 DOM 操作触发 ✓ 正确答案 D 三者攻击向量完全相同
# 18. CSP 的 script-src/object-src/frame-ancestors 与 DPoP（RFC 9449）的现代取舍 A CSP 与 DPoP 功能相同 B script-src 限制脚本、object-src 禁插件、frame-ancestors 防点击劫持，DPoP 防 token 重放 ✓ 正确答案 C frame-ancestors 限制脚本来源 D DPoP 与 token 安全无关
# 19. CORP/COEP 的跨域资源策略 在 XSS/CSRF 防护的协作 A COEP 放宽跨源资源加载 B CORP/COEP 与安全无关 C CORP 限制资源被跨源嵌入，COEP 强制声明，减少跨源注入与数据泄露 ✓ 正确答案 D CORP 只限制 Cookie
# 20. Markdown 渲染（marked、markdown-it） A 需禁用原始 HTML、协议白名单并 DOMPurify 消毒，防止 XSS ✓ 正确答案 B Markdown 渲染天然安全，无 XSS C 危险链接协议（javascript:）无需处理 D 渲染结果不能消毒
# 21. Prototype Pollution 在前端 XSS 攻击链的应用 A 原型污染只影响单个对象 B 合并用户输入是安全的 C 原型污染与 XSS 无关 D 原型污染通过不安全合并污染 Object.prototype，可构成 XSS/逻辑绕过攻击链 ✓ 正确答案
# 22. HTTP/2 的 Server Push 已废弃，被 103 Early Hints 取代的取舍 A Server Push 仍被支持 B Early Hints 是服务端推送 C Server Push 因无法感知缓存被弃，103 Early Hints 让浏览器主动请求关键资源 ✓ 正确答案 D Early Hints 与缓存无关
# 23. Trusted Types 与 CSP 的协同防护 A CSP 限制脚本来源，Trusted Types 强制 DOM 注入类型安全，协同防 XSS ✓ 正确答案 B Trusted Types 与 CSP 互斥 C CSP 无法启用 Trusted Types D 两者只能用于服务端
# 24. Sanitize API（DOMPurify）与风险（Mutation XSS） A mXSS 利用解析-序列化-再解析的结构变化绕过 sanitizer ✓ 正确答案 B 净化后的 HTML 永远安全 C mXSS 与解析器无关 D DOMPurify 无 mXSS 风险
# 25. OWASP DOM XSS 测试用例在前端审计清单的工程价值 A DOM XSS 用例只用于学习，无工程价值 B DOM XSS 无法被测试 C 审计清单无法自动化 D 把 OWASP DOM XSS 用例纳入审计清单可系统性检测 DOM 注入并防回归 ✓ 正确答案
# 26. 浏览器 DevTools Network 面板的瀑布流分析 A 瀑布流只显示总耗时，无阶段信息 B 瀑布流分解队列、DNS、连接、TTFB、下载等阶段，用于定位性能瓶颈 ✓ 正确答案 C 瀑布流无法分析资源大小 D TTFB 长与服务器无关
# 27. WireShark/Charles Proxy 在 HTTPS 抓包的 CA 证书与中间人原理 A HTTPS 抓包无需解密即可查看内容 B 代理用自签 CA 让客户端信任并解密转发（MITM），Wireshark 用密钥日志解密 ✓ 正确答案 C CA 证书与抓包无关 D 只能在服务器端抓包
# 28. HTTP Alt-Svc 与 Alt-Used 在服务发现与协议升级的应用 A Alt-Svc 声明替代服务/协议，客户端据此升级（如 HTTP/3） ✓ 正确答案 B Alt-Svc 是客户端请求头 C Alt-Svc 与协议升级无关 D Alt-Used 是服务器响应头
# 30. HAR 文件的导出与跨环境对比 A HAR 只记录请求 URL B HAR 不含敏感信息，可随意分享 C HAR 无法导出 D HAR 记录完整请求/响应信息，可跨环境对比分析性能差异 ✓ 正确答案
# 31. TCP Fast Open（TFO）在减少握手 RTT 的服务端支持 A TFO 在 TCP 握手中携带数据，减少一个 RTT，需服务端支持 ✓ 正确答案 B TFO 会增加握手 RTT C TFO 无需服务端配置 D TFO 与 TLS 无关
# 32. CDN 节点故障的诊断方法 A 只能依赖 CDN 厂商 B 故障一定在 CDN C 用 dig/curl/ping/对比源站分层排查，定位是节点、网络还是回源问题 ✓ 正确答案 D 无需检查 DNS 解析
# 33. pcap/Wireshark 在端到端网络抓包调试的工程价值 A Wireshark 只能看 HTTP 层 B Wireshark 可分析 TCP 重传、丢包、TLS 握手等底层网络问题 ✓ 正确答案 C Wireshark 无法解析 TLS D 抓包无需关心网络层
# 34. chrome://net-export 与 netlog 在生产环境的网络问题分析 A net-export 导出浏览器网络日志，用 netlog-viewer 分析定位连接/DNS/代理/TLS 问题 ✓ 正确答案 B netlog 只记录页面 DOM C netlog 无法导出 D netlog 与网络问题无关
# 35. whistle/Charles/Proxyman 在本地 HTTPS 解密的工程取舍 A Charles 完全免费 B 三者都无法解密 HTTPS C whistle 规则驱动、Charles 全面跨平台、Proxyman 面向 macOS，都需 CA 证书解密 HTTPS ✓ 正确答案 D whistle 无法跨平台
# 36. Charles Map Local / Map Remote 在本地替换线上资源与 SSR 联调的工程价值 A Map Local 替换本地文件、Map Remote 重定向远程，用于本地调试与 SSR 联调 ✓ 正确答案 B Map Local 把请求重定向到远程 C 两者都只能 mock D Map Local 无法替换接口
# 37. QUIC 0-RTT 与 1-RTT 在 CDN/移动弱网环境的兼容性踩坑与版本回落策略 A QUIC 在所有环境完美可用 B QUIC 无需兼容性考虑 C 0-RTT 无任何风险 D QUIC 0-RTT 省 RTT 但有重放风险，UDP 可能被阻断，需回退 HTTP/2 兜底 ✓ 正确答案
# 38. 请求优先级（fetch priority、AbortSignal 嵌套）在高并发场景下的调度策略 A fetchpriority 提示优先级，AbortSignal.any() 组合取消源，用于高并发调度与取消 ✓ 正确答案 B fetchpriority 是浏览器强制的优先级 C AbortSignal 无法嵌套 D 优先级与调度无关
# 39. SVG/HTML 内嵌 SVG 与 CSS url() 注入的边界 A SVG 可携带脚本需净化，CSS url() 需限制协议（禁 javascript:） ✓ 正确答案 B SVG 内嵌脚本天然安全 C CSS url() 无法注入 D 两者都无需防御
# 40. Service Worker 的 XSS 注入与 source map 泄漏 A 两者与安全无关 B source map 可以随意发布 C SW 无需保护 D SW 被注入可接管请求，生产 source map 应控制访问，防源码泄露 ✓ 正确答案
# 41. Mutation XSS（mXSS）的原理与防御 A mXSS 无法防御 B 用最新 sanitizer、避免二次解析、受控渲染与 Trusted Types 防 mXSS ✓ 正确答案 C 一次性净化即可永绝 mXSS D mXSS 与解析器无关
# 42. HTML 转义与安全上下文（HTML、Attribute、JS、URL） A HTML 实体编码适用于所有上下文 B HTML、Attribute、JS、URL 上下文编码规则不同，必须匹配输出位置 ✓ 正确答案 C 转义与上下文无关 D 框架自动处理所有上下文
# 43. Content Security Policy（CSP） A CSP 只能限制图片 B CSP 白名单限制脚本/样式/连接来源，防 XSS，用 nonce/hash 与 report-only 部署 ✓ 正确答案 C CSP 与 XSS 无关 D CSP 无法限制数据外传
# 44. DOMPurify 的钩子（hooks）在自定义清理规则的工程扩展 A 钩子只能做净化前处理 B 钩子无法定制属性处理 C 钩子（uponSanitizeElement/Attribute、before/after）可自定义清理规则 ✓ 正确答案 D 钩子会破坏所有安全
# 45. URL 协议白名单（javascript:、data:）在用户输入的工程防御 A 危险协议（javascript:）无需过滤 B data: 协议总是安全的 C 用协议白名单只允许 http/https/mailto 等，拒绝 javascript:/data:，防 XSS ✓ 正确答案 D 前端校验即可，无需后端
# 46. 模板注入（Template Injection）在 SSR 框架（Angular、Vue） A 用户输入可作为模板表达式安全计算 B 模板注入与 SSR 无关 C 把用户输入当作模板表达式/动态编译会触发模板注入，应避免输入当代码 ✓ 正确答案 D 插值表达式天然安全执行任意代码
# 47. XSS 在第三方 iframe（嵌入广告）的工程隔离策略 A 第三方 iframe 可自由访问父页面 B sandbox 会增强 iframe 权限 C 用 sandbox 限制 iframe 权限、CSP 限制来源、postMessage 受控通信隔离 ✓ 正确答案 D 第三方 iframe 无需隔离
# 48. Trusted Types 的 createPolicy 在框架集成的现代应用 A Trusted Types 只能用于服务端 B React 完全支持 Trusted Types C createPolicy 与框架无关 D Angular 默认启用 Trusted Types，createPolicy 定义可信 DOM 注入 ✓ 正确答案
# 49. XSS Payload 在客户端绕过（WAF、CSP）的工程排查 A WAF 与 CSP 无法被绕过 B CSP 严格配置就不会被绕过 C 编码与绕过无关 D 编码混淆、mutation、CSP 配置漏洞（unsafe-inline）可绕过，需审计输出点与测试 ✓ 正确答案
# 50. DOMPurify 与 Trusted Types 协作在现代工程的工程价值 A DOMPurify 净化内容，Trusted Types 强制注入路径，组合实现纵深防御 ✓ 正确答案 B 两者功能重复 C Trusted Types 已取代 DOMPurify D 两者只能二选一
# 51. JSON 注入（JSON Hijacking）的现代防御策略 A 用 CORS + 正确 Content-Type + nosniff/CORB + 安全 Cookie 防御 JSON 劫持 ✓ 正确答案 B 用 JSONP 最安全 C 前缀注入无法防劫持 D 现代仍推荐 JSONP
# 52. innerHTML、outerHTML、insertAdjacentHTML 的 XSS 风险与现代替代 A innerHTML/outerHTML/insertAdjacentHTML 解析 HTML 有 XSS 风险，用 createElement/textContent 替代 ✓ 正确答案 B innerHTML 自动转义，无风险 C textContent 会解析 HTML D 所有 DOM API 风险相同
# 53. Trusted Types 的浏览器支持与 polyfill（DOMPurify） A 所有浏览器都支持 Trusted Types B 不支持的环境无需防护 C DOMPurify 无法兜底 D Trusted Types 支持有限，用 DOMPurify 净化兜底，检测 trustedTypes 可用性 ✓ 正确答案
# 54. XSS 在 SVG 与 XML 解析中的工程攻击向量 A SVG 可内嵌脚本/foreignObject/事件，XML 有 XXE 风险，需净化与禁用外部实体 ✓ 正确答案 B SVG 无法执行脚本 C XML 外部实体无风险 D 上传 SVG 无需净化
# 55. 前端富文本编辑器（Tiptap、Slate）的 XSS 防御与现代应用 A 用 schema 白名单 + DOMPurify 净化 + Trusted Types 渲染，防富文本 XSS ✓ 正确答案 B 富文本输出天然安全 C 富文本无需净化 D onerror 属性无风险
# 56. CSP 的 nonce-source 与 hash-source 在内联脚本与现代构建产物的工程取舍 A nonce 静态不变，hash 每次变化 B nonce 允许动态内联脚本（需服务端随机），hash 允许静态内联脚本（内容变需更新） ✓ 正确答案 C 两者都禁止内联脚本 D hash 需要服务端随机生成
# 57. CSP Level 3 的 strict-dynamic 在动态脚本加载信任传递的现代工程价值 A strict-dynamic 放宽所有域名 B strict-dynamic 会扩大攻击面 C strict-dynamic 与 nonce 无关 D strict-dynamic 让 nonce/hash 脚本与动态加载的脚本信任传递，避免通配域名 ✓ 正确答案
# 58. DOM Clobbering（id 属性污染与全局变量冲突） A id 属性无法影响全局变量 B 注入 id/name 元素可覆盖全局变量，导致逻辑绕过或 XSS，需净化与保护 ✓ 正确答案 C DOM Clobbering 与服务端无关 D 全局变量是安全的判断依据
# 59. MutationObserver 在检测 DOM 注入恶意内容的运行时监控价值 A MutationObserver 能完全阻止恶意脚本执行 B MutationObserver 事后监控 DOM 变化，适合检测/审计，预防靠 CSP/Trusted Types ✓ 正确答案 C MutationObserver 无法检测 DOM 变化 D 检测到注入即可阻止执行
# 60. Service Worker 的 unsafe-eval 与 CSP 在 PWA 字符串编译的边界 A eval 在 CSP 下无需限制 B SW 不受 CSP 约束 C unsafe-eval 提升安全性 D 应避免 eval 等字符串编译，CSP 禁 unsafe-eval 防 XSS，用安全替代 ✓ 正确答案
# 61. eval()/Function()/setTimeout("string") 在 CSP unsafe-eval 禁用后的代码动态执行方案 A eval 仍可执行 B setTimeout 字符串不受 CSP 限制 C 用传函数、JSON.parse、配置映射、动态 import 替代 eval/Function/setTimeout(string) ✓ 正确答案 D 动态执行必须用 eval
# 62. 模板引擎（Handlebars、EJS、Mustache） A 模板引擎默认不转义 B 模板引擎无法转义 C 原始输出天然安全 D 模板引擎默认转义，但原始输出（{{{}}}/<%- %>）不转义，用于不可信数据会 XSS ✓ 正确答案
# 63. Sanitizer API（Element.setHTML）相比 DOMPurify 在浏览器原生 XSS 防护的工程价值 A Sanitizer API 已完全取代 DOMPurify B setHTML 是浏览器原生净化，性能好但支持有限，DOMPurify 成熟跨浏览器兜底 ✓ 正确答案 C Sanitizer API 无法净化 D 两者功能完全不同
# 64. SVG 标签中的 <script>、<foreignObject> 与数学公式（MathML）的 XSS 攻击面 A SVG 的 foreignObject 无法嵌入 HTML B MathML 无 XSS 风险 C SVG script/foreignObject 与 MathML 可构造 XSS/mXSS，需净化器禁用危险元素 ✓ 正确答案 D SVG 脚本无法执行
# 65. React 19 的 Server Components 默认不暴露 client 边界对 XSS 攻击面的工程价值 A Server Components 默认不暴露 client 边界，减少客户端 XSS 面，但服务端输出仍需净化 ✓ 正确答案 B Server Components 彻底消除 XSS C Server Components 与 XSS 无关 D Server Components 增加攻击面
# 66. CSP 的 report-uri/report-to 与 Report-Only 模式在 CSP 部署阶段的渐进实施策略 A Report-Only 会阻止违规资源 B Report-Only 与强制执行相同 C report-uri 是全新的 Reporting API D 先 Report-Only 收集违规、调整策略，再强制并持续监控，安全部署 CSP ✓ 正确答案
# 67. DOMPurify 4.x 在 Angular、React、Vue 的 SSR 场景下作为 server-side sanitizer 时，如何避免在 hydration 后 client 端 sanitizer 与 server 端规则不一致导致的 XSS 漏洞——sanitize 配置在 SSR→CSR 传递链上应如何序列化与签名 A 共享 sanitize 配置并在 SSR 输出签名，客户端校验签名信任，避免 hydration 不一致 XSS ✓ 正确答案 B server 与 client sanitizer 规则可任意不同 C 签名与净化无关 D hydration 时二次净化是安全的
# 68. Trusted Types policy 创建的命名（命名空间） A policy 名字随意且不受控 B 同名 policy 可重复创建 C CSP 的 trusted-types 指令可白名单限制允许的 policy 名，按用途命名实现细粒度控制 ✓ 正确答案 D 命名与 CSP 无关
# 69. Mutation XSS（mXSS）通过浏览器 HTML 解析器的 innerHTML→序列化的非线性变换绕过 sanitizer——React/Vue 的 reconciliation 流程、Trusted Types 与 DOMPurify 在哪些路径上仍存在 mXSS 攻击面 A 净化后内容二次解析不会触发 mXSS B 净化后内容被序列化再解析会触发 mXSS，需避免二次解析、用最新 DOMPurify 与 Trusted Types 兜底 ✓ 正确答案 C Trusted Types 完全解决 mXSS D React/Vue 的 dangerouslySetInnerHTML 无 mXSS 面
# 70. X-Content-Type-Options: nosniff 如何关闭浏览器 MIME 嗅探并阻断“伪装成图片/文本的 HTML 被当作脚本执行”的存储型 XSS 链路，nosniff 对 script/style 资源 MIME 不匹配时的拦截行为，以及部署时应配套哪些正确的 Content-Type 判断标准？ A nosniff 会保持 MIME 嗅探 B 无需设置正确 Content-Type C nosniff 与 XSS 无关 D nosniff 关闭嗅探，阻断伪装 HTML 被当脚本执行，script/style 的 MIME 不匹配会被拦截 ✓ 正确答案
