前端监控与边缘安全

• SLI 的选择：可用性、延迟、错误率的可度量定义
• SLO 的设定方法：基线 → 目标 → 预算窗口
• SLO 的治理闭环：告警、错误预算与发布关联

定义 SLO 分四步：选 SLI——把用户体验转成可度量指标，如页面可用率（首屏成功渲染的比例，剔除网络不可达）、交互延迟达标率（INP P75 小于阈值的会话占比）、错误率（JS 异常率、请求失败率）；定目标——先收集基线（当前 P75/P95 实测值），设定「跳一跳够得着」的目标（如 INP P75 < 250ms、可用率 99.5%），目标要能区分「真退化」与「噪声」；设窗口——SLO 在滚动窗口（如 28 天）内评估，容忍偶发抖动而不触发告警，只有持续违反才告警；建闭环——定义错误预算（100% - SLO），预算耗尽即冻结高风险发布，把 SLO 与发布节奏绑定。治理要点：SLO 必须有数据支撑的基线、可解释的度量口径（采样率、异常剔除规则），并定期评审（目标过紧导致告警疲劳、过松失去意义），保证 SLO 是「可执行的承诺」而非「文档里的数字」。

回答按「选指标 → 定目标 → 设窗口 → 建闭环」四步展开，强调基线驱动与错误预算机制，最后点出评审与防僵化，体现 SLO 是持续治理体系而非一次性设定。

• INP 的语义：交互到下一帧绘制的延迟，事件处理时长的汇总
• Long Task API（longtask）提供的归因数据：duration、startTime、attribution
• 归因链路：INP 异常 → 采样长任务 → 定位任务来源与代码

INP（Interaction to Next Paint）度量用户每次交互到下一帧绘制之间的最长延迟，其构成是事件处理、渲染与合成的时间总和；当 INP 超阈值（如 200ms），瓶颈通常是主线程被长任务占用——交互事件排队等待长任务结束。归因链路：监控层用 PerformanceObserver 采集 longtask（duration、startTime、attribution 中的容器信息），把「INP 异常会话」与「该时间窗内的长任务」关联（INP 发生时刻附近的 longtask 即嫌疑任务）；定位层按长任务归因到脚本文件与函数（attribution 提供脚本 URL，配合 source map 还原到源码），并分析其类型（重计算、大 DOM 操作、同步循环、垃圾回收）；治理层对高频长任务做拆分（requestIdleCallback 分片、Web Worker 移出主线程、虚拟化渲染），并以「长任务时长/次数」作为 INP 的先行指标纳入监控基线。闭环要点：INP 是结果指标，longtask 是过程指标，二者结合才能从「知道慢」到「知道哪里慢」。

本题考性能归因方法：先讲 INP 的构成与长任务的关系（交互排队被长任务阻塞），再讲 longtask API 提供的数据与关联方法，最后落到定位与治理闭环，强调结果指标 + 过程指标的组合。

• 浏览器对跨域脚本错误信息遮蔽的机制（同源策略）
• crossorigin 属性（anonymous/use-credentials）与 CORS 响应头
• source map 上传与符号化还原的工程链路

遮蔽机制：浏览器按同源策略，对跨源脚本抛出的错误只暴露 "Script error."，不提供行号与堆栈，防止信息泄露到恶意第三方页面。还原链路第一步是解除遮蔽：给跨域 script 标签加 crossorigin="anonymous"，且 CDN 返回 Access-Control-Allow-Origin 响应头，此时错误对象才包含完整信息（浏览器以 CORS 模式加载脚本并放行错误详情）；第二步是符号化：发布时把 source map 上传到监控平台并归档产物清单（map 文件名与版本对应），还原服务用堆栈中的脚本 URL 与行号列号查找对应 map，映射回源码文件与函数；注意 map 不应公开在 CDN 上被直接下载（源码泄露风险），监控平台应在受控环境完成符号化。工程要点：crossorigin 与 CORS 头缺一不可、source map 与产物版本必须严格对齐（版本漂移会导致还原错乱）、对同源部署的应用同样建议上传 map 以获得高质量堆栈。

本题考错误还原全链路：先讲遮蔽的安全原因，再讲 crossorigin + CORS 头解除遮蔽，最后讲 source map 上传、归档与受控符号化，突出「安全遮蔽 → 显式授权 → 符号化」的完整工程理解。

• 边缘 WAF 的防御位置优势：靠近用户、尽早拦截
• 收益：降低回源压力、拦截前置、容量与延迟
• 取舍：规则一致性、隐私与合规边界

下沉收益有四：拦截前置——攻击流量在离用户最近的边缘节点被过滤，不进入源站，源站暴露面显著减小（DDoS 清洗、CC 攻击、恶意爬虫在边缘终止）；回源节省——边缘缓存与规则过滤减少请求回源，源站容量需求与带宽成本下降；延迟优化——安全检测与业务处理同层执行，合法请求无需多一跳安全链路；容量弹性——边缘天然分布式，按区域就近承接流量洪峰。取舍与挑战：规则一致性——边缘与源站多层 WAF 需统一规则版本与判定口径，避免「边缘放行、源站拒绝」的裂口；合规边界——数据出境、日志留存等合规要求决定哪些检测必须本地执行；可见性——边缘拦截日志需回流到统一安全平台，否则安全团队对边缘层「盲区」。工程实践：边缘执行高频、无状态的规则（IP/UA 信誉、速率、签名），有状态与深度检测回源站，分层协同。

回答按「收益（前置拦截、省回源、低延迟、弹性）→ 取舍（规则一致性、合规、可见性）→ 分层实践」组织，强调边缘 WAF 是「防御前移」而非「替代源站防护」。

• DDoS 的攻击形态与边缘清洗的位置优势
• 边缘函数在清洗中的角色：流量整形、速率限制、挑战校验
• 清洗的边界：容量与状态，回源保护

DDoS 缓解的核心是「在攻击流量到达源站前将其消化」：边缘函数运行在全球分布的边缘节点，可对每个节点的流量就地处理——协议与 TLS 层由边缘网络兜底（SYN flood 等在网络层终止），应用层的 CC/爬虫流量由边缘函数做流量整形：按来源 IP、ASN、会话与行为特征做速率限制，超过阈值直接丢弃或返回质询（JS challenge、验证码），配合边缘缓存放行合法热点请求，实现「合法用户就近服务、攻击流量就地终止」。就近清洗的要点：规则要尽量无状态（边缘函数不宜维护大规模会话状态，状态可放在边缘 KV/存储）；清洗决策要可回退（误杀率高时降级放行并人工复核）；攻击特征要能快速下发（规则热更新到所有边缘节点）；清洗之外必须做源站保护——限源站可见请求量、源站 IP 隐藏（代理/隧道），避免攻击者绕过边缘直达源站。

回答按「攻击形态 → 边缘函数的分层清洗动作（限速、质询、缓存）→ 边界与源站保护」组织，强调边缘清洗「无状态、可回退、规则热更新」的工程要求。

• 数据驻留的合规背景：GDPR 等对数据出境的限制
• 边缘执行的区域绑定：区域部署与数据本地化
• 数据流治理：处理、存储与日志的区域限制

数据驻留要求「特定区域的数据在该区域内处理与存储」：合规背景下（GDPR、各国数据本地化法规），个人信息不得随意跨境传输。边缘侧的实现：区域绑定部署——把处理用户数据的边缘函数绑定部署到指定区域（如欧洲流量只路由到欧洲边缘节点执行），利用边缘「代码随节点分布」的特性天然实现区域隔离；数据本地化存储——边缘 KV/缓存按区域隔离，同一用户的数据只写入其所属区域的存储，不在全局副本间流动；数据流治理——函数出口审计（外发请求目的地白名单）、日志与遥测按区域留存且去标识化，跨境请求显式脱敏或拒绝。取舍：区域绑定降低弹性（该区域节点故障不能由他区承接）、增加运营复杂度（多区域版本一致性与密钥管理），因此常按「数据分类」分级——强敏感数据严格驻留，低敏数据允许全局流动，用策略引擎统一表达。

本题考合规工程：先讲数据驻留的合规驱动力，再讲「区域部署、本地化存储、出口审计」三类实现，最后给数据分级与成本取舍，体现合规需求转化为架构约束的方法。

• 错误预算的定义与计算（100% - SLO）
• 预算消耗与发布冻结、发布节奏的联动
• 预算机制的目标：在可靠性与迭代速度间平衡

错误预算 = 100% - SLO：SLO 允许的不可用/不良体验时间窗就是团队的「犯错额度」，预算耗尽前可以放心迭代，耗尽后必须停下来修复（冻结高风险发布、聚焦稳定性）。与前端的结合：前端把预算细分为可用率预算（页面白屏/加载失败）与体验预算（INP 超标、错误率超标），RUM 持续累计消耗；发布节奏由预算状态驱动——预算充足时按正常节奏迭代，预算接近耗尽时降速（只发低风险变更），耗尽时强制稳定期（只允许修复性发布）。机制的价值在两端：对业务方，预算把稳定性目标量化成可沟通的数字；对研发，预算提供了「快速迭代的安全边界」，避免一刀切的发布限制。落地要点：预算窗口（滚动 28 天）避免单点事故直接冻结全部发布；预算消耗的归因要落到版本（哪个发布吃掉了预算），否则「集体买单」打击发布积极性。

回答先定义预算与 SLO 的关系，再讲预算状态与发布节奏的联动（充足/接近耗尽/耗尽三态），最后讲机制平衡价值与落地要点（滚动窗口、版本归因），体现「预算即发布治理工具」。

• 告警疲劳的成因：固定阈值误报、指标自然波动
• 动态阈值：按历史基线计算正常波动区间，异常才告警
• 动态阈值的工程要点：基线窗口、季节性、置信度与降级

告警疲劳源于固定阈值与指标自然波动冲突：前端指标受流量、时段、网络环境与版本影响，固定阈值（如错误率 > 1% 告警）在高峰或活动期频繁误报，团队逐渐忽视告警，真正的故障反而被淹没。动态阈值按「历史基线 + 波动区间」判定：系统对指标（错误率、INP、可用率）维护滚动基线（如近 7 天同小时段的分位数），当日值显著偏离基线（超过 N 倍标准差或跨过基线的分位差）才告警；这样「缓慢退化」与「突增」都能被识别，而正常波动不打扰。实施要点：基线窗口要匹配季节性（工作日/周末、活动期分开建基线）；新版本上线期用「对比基线」（同比上一版本或同版本前一日）避免版本差异引发误报；低流量时段置信度不足时自动降级（少告或不告）；告警级别分级（页面级 → 应用级 → 集群级），配合抑制规则（同根因合并）与告警路由（按归属团队），从「每个尖峰都响」变成「真问题才响」。

回答按「成因 → 动态阈值原理（基线 + 波动区间）→ 工程要点（季节性、版本对比、置信度、抑制路由）」组织，强调告警治理的目标是「把告警变成可行动的信号」。

• 拨测与 RUM 的采集方式差异：主动 vs 被动、样本 vs 全量
• 各自的优势与盲区
• 互补组合：拨测兜底发现 + RUM 还原真实分布

拨测是主动监控：脚本从外部节点模拟真实用户访问关键路径，样本固定、环境可控，能主动发现「没人访问时也存在的问题」（白屏、CDN 故障、第三方服务不可用），且不受用户隐私与采样影响；RUM 是被动监控：从真实用户浏览器采集全量数据，反映真实设备、网络与地域分布，但只能覆盖「有用户访问的时刻」，且受采样与隐私限制。互补关系：拨测负责「确定性发现」——持续盯住核心路径，故障第一时间报警（不受流量影响）；RUM 负责「真实性还原」——量化真实用户体验分布（P75/P95、分地域分版本），验证拨测未覆盖的长尾场景。组合实践：拨测结果异常时结合 RUM 判断影响面（是普遍故障还是特定网络/版本），RUM 指标退化时用拨测定位「是页面本身问题还是用户环境问题」，二者互为交叉验证；拨测样本的分布设计（多地域多运营商）弥补 RUM 样本偏差。

本题考监控体系互补：先对比「主动/被动、样本/全量、可控/真实」的差异，再讲两者的盲区如何被对方覆盖，最后给组合实践的交叉验证场景，体现监控架构的整体思维。

• traceId 的生成与透传链路（前端 → 网关 → 服务）
• 请求头注入与 CORS 允许头配置
• 关联分析的价值：端到端时延拆解与错误定位

关联的核心是「同一请求前后端共享同一标识」：前端 SDK 在发起请求时生成或获取 traceId，通过自定义请求头（如 x-trace-id）或标准 W3C traceparent 透传，网关与后端服务沿用该 ID 贯穿调用链，后端日志与 APM 以它关联；CORS 场景需在 Access-Control-Allow-Headers 中显式放行该头，跨域与预检请求要正确处理。实现要点：页面级 traceId 在会话开始时生成，可对多请求复用（页面加载链），SSR 场景由服务端生成注入到页面。关联分析价值：端到端时延拆解——同一 traceId 下，前端等待时间（TTFB 后的解析渲染）、网络时间、后端处理时间（APM 的各 span）一目了然，定位「慢在谁」；错误关联——前端报错（请求失败、接口错误）直接跳到后端对应链路的日志与调用栈，省去跨系统对账；业务链路还原——跨端（前端 → BFF → 服务）的完整调用轨迹支撑根因分析。落地时注意 traceId 的上报规范统一（字段名、长度、采样策略对齐前后端）。

回答按「标识生成与透传（含 CORS）→ 链路实现 → 关联分析价值（时延拆解、错误定位、轨迹还原）」组织，突出「前后端统一规范」是关联分析的前提。

• 噪声邻居问题：租户间资源争抢导致的性能干扰
• 隔离手段：配额、速率限制、优先级调度与分区
• 隔离与资源利用率的平衡

噪声邻居指某个高消耗租户挤占共享资源，导致其他租户延迟劣化——边缘节点上多个租户共享 CPU/内存/带宽时尤为突出。防护手段分四层：配额层——按租户设定硬性资源配额（CPU 时间片、内存上限、并发数），超限即限制或排队；速率限制层——按租户限制请求速率与带宽，防止突发流量打满节点；调度层——优先级与权重调度（核心业务租户高优先级、批处理低优先级），低优任务在空闲时运行；分区层——关键租户独占节点/容器（物理或逻辑分区），彻底隔离但成本高。实现要点：隔离需要「可观测」支撑——按租户维度的资源用量与延迟指标实时监控，噪声检测到后自动调整配额；防护阈值可配置且带保护（防止误伤导致租户间投诉升级为管理问题）。平衡：完全隔离浪费资源、完全共享风险大，工程上按租户信任级别分级——高信任共享 + 配额保护，关键租户独占保障。

本题考多租户治理：先定义噪声邻居问题，再按「配额、限速、调度、分区」四层展开，最后讲可观测性与分级隔离的平衡，体现基础设施治理的工程分寸。

• 密钥不外泄：避免密钥进代码与产物
• 区域化 secret 的存储与注入
• 短时效令牌：按需签发、动态获取、最小暴露面

密钥管理的原则是「密钥不落代码、动态获取、最小生命周期」：密钥直接写进函数代码或打包产物是重灾区（产物会被拉取分析）。区域化 secret：密钥存储在边缘平台的 secret 服务中，按区域与函数绑定，运行时注入环境变量或经 API 获取，函数代码只见变量名不见明文；区域化让数据驻留区域的密钥不出该区域，配合轮换机制（定期更换，函数重启生效）。短时效令牌：对第三方服务或下游鉴权，不在函数里存长期凭证，而是运行时按需向令牌服务申请短期令牌（如 5-15 分钟有效），用完即失效——即使令牌泄露，暴露窗口极小；令牌申请可结合身份验证（函数身份、mTLS）与最小权限（仅申请当前操作需要的 scope）。工程要点：secret 访问审计（谁在哪个区域读取了哪个 secret）、密钥轮换与版本管理、以及应急吊销路径（发现泄露可立即吊销），构建与部署流水线中做密钥扫描防止误提交。

本题考凭据安全工程：先立「不落代码、动态获取、短生命周期」原则，再分别讲区域化 secret 的存储注入与短时效令牌的按需签发，最后落到审计、轮换与吊销的运维闭环。

• SSRF 的风险：函数可发起请求，可能被利用访问内网/元数据服务
• 出口管控：出口白名单、协议限制与目标校验
• 元数据服务保护与防护纵深

SSRF 指服务端请求被攻击者诱导访问预期之外的地址：边缘函数能发起网络请求，若请求目标由外部输入控制（URL 参数、回调地址、webhook），攻击者可让其访问云元数据服务（获取临时凭证）、内网地址或内部 API。出口管控要点：出口白名单——函数出站请求按「目标域名/IP 白名单」限制，仅允许业务必需的目的地（平台强制、函数配置声明），白名单外的请求直接拒绝；协议与端口限制——仅允许 https/目标端口（如 443），阻止 file://、内网网段（RFC1918 与元数据网段 169.254.169.254）访问；目标解析校验——对动态 URL 做 DNS 解析后校验 IP 归属（防域名白名单但解析到内网），并做重定向跟随策略（防止跳转到内网）。纵深防护：元数据服务侧加访问令牌（IMDSv2 的 token 机制）、网络层做微分段（函数网络与内网隔离）、日志审计出站请求，任一输入可控的请求路径都要做目标校验。

回答先讲 SSRF 的形成（外部输入控制目标 + 函数出站能力），再讲三层出口管控（白名单、协议/网段限制、解析后校验），最后补元数据保护与审计纵深，体现「默认拒绝、显式放行」的安全基线。

• 速率限制的维度：客户端维度与路由维度
• 限速算法：固定窗口、滑动窗口与令牌桶
• 配额设计与超额处理：状态存储与响应策略

设计要点是按「客户端 × 路由」双维度控制：per-client 限速防单一客户端滥用（按 IP/用户/会话维度，如每用户每分钟 60 次），per-route 限速防特定接口被打爆（如登录接口、导出接口单独限速，按路由配置额度）；组合方式：客户端配额先校验（超过即拒绝）、路由配额后校验（防止总量过载），双层叠加形成「个体不滥用、总盘不被打穿」。算法选型：固定窗口简单但临界突刺（窗口边界双倍请求），滑动窗口与令牌桶更平滑（令牌桶支持突发与平均速率分离），边缘场景用分布式限速——状态存边缘 KV/计数服务，按节点就近计数，注意分布式一致性（最终一致即可，限速允许近似）。配额管理：超额响应用 429 + Retry-After 头（客户端可正确退避），配额按租户/时段动态调整，限速指标（拒绝数、命中率）纳入监控，防止限速策略本身成为故障点（误杀合法流量）。

本题考限速工程：先讲双维度设计（客户端防滥用 + 路由防过载），再讲算法选型与分布式状态，最后落到响应语义（429/Retry-After）与可观测性，体现完整的限速治理闭环。

• 页面卸载场景下 XHR/fetch 被浏览器终止的问题
• sendBeacon 与 fetch keepalive 的机制与限制（体积、队列）
• 失败重试与批量合并的上报设计

页面卸载（跳转、关闭）时普通 XHR/fetch 会被浏览器取消，导致「最后一批」监控数据丢失。解决手段：sendBeacon 以「浏览器接管」方式发送数据，卸载期间仍能完成提交，但体积受限（通常 64KB）且无法自定义请求头与读取响应；fetch keepalive 提供类似保证并支持自定义头，同样有体积与连接数限制（keepalive 队列总大小约 64KB）；取舍：小体积高频事件用 sendBeacon，需要自定义头或并发上报用 keepalive，超大负载（会话回放片段）在卸载前主动 flush 分批提交。可靠性设计：上报失败重试——带退避的有限重试（指数退避、上限次数），卸载场景下重试依赖 keepalive/beacon；批量合并——把短时间窗内的同类事件（错误、指标）合并为批量请求，减少请求数、提高吞吐，批量在页面生命周期关键点（visibilitychange、beforeunload）主动 flush；上报本身不阻塞主流程（fire-and-forget），并设置上报失败的自愈（本地暂存队列 + 下次页面加载补发）。

回答按「卸载场景的问题 → beacon/keepalive 机制对比与取舍 → 重试与批量设计」组织，强调「卸载必达」与「常态低损」两种需求的分别满足。

• JWT 校验下沉边缘的时机：请求进入节点即验签
• 回源信任模型：边缘可信后源站如何接管
• 校验的粒度与失效处理：签名、过期、吊销与降级

下沉的时机是「请求在边缘节点被处理的最早阶段」：TLS 终止与基础路由之后、业务分发之前，边缘对请求中的 JWT 做验签（用公开密钥/缓存密钥验证签名与过期时间），验证失败的请求直接拒绝，不回源——攻击与无效流量在边缘终结，源站压力大减。回源信任模型：边缘验签通过后，把验证结果（claims、用户身份、或新签发的内部令牌）透传给源站，源站信任边缘的验证结果，不再重复验签；信任边界的核心是「边缘到源站链路可信」——用 mTLS 或内部网络保护回源链路，防止绕过边缘直连源站（源站必须只接受来自边缘的流量），同时源站保留对敏感操作的二次校验（鉴权下沉不意味着源站零校验）。工程要点：JWT 的公钥分发与轮换（边缘缓存公钥、失效时间对齐）；吊销状态（黑名单/会话版本）放在边缘可访问的 KV 中同步；校验失败/降级策略——边缘判定服务异常时降级放行回源校验（保证可用性优先于拦截）。

回答按「下沉时机（最早阶段验签）→ 回源信任模型（边缘可信 + mTLS 链路 + 敏感操作二次校验）→ 密钥/吊销/降级工程要点」组织，强调信任模型「边缘负责前置过滤、源站保留关键校验」。

• 采样率的设定依据：流量、成本与统计精度
• 分层采样与样本权重的偏差修正
• 采样的适用边界：性能指标可采样，错误类建议全量

采样率的设定是「精度与成本的权衡」：流量大时全量上报成本高（带宽、存储、处理），按 1%-10% 采样可大幅降本，但样本量下降使统计精度与长尾发现能力下降。设定依据：日活与上报量级、业务对精度的要求（P95 估算需要的样本量）、以及数据的用途（趋势监控可低采样，容量规划需要高精度）。偏差修正：不同用户群体（设备、地域、版本）采样率不一致会造成分布扭曲，需用分层采样——按关键维度分层，每层独立采样并记录层权重，统计时按权重加权回推总体（如低端机层权重高，结果按权重还原真实分布）；随机采样保证无偏性，避免「只采到特定环境」。适用边界：性能与体验指标可采样（趋势统计足够），错误与崩溃类建议全量或高采样（低频高价值事件采样会漏报）；会话回放等重负载按低采样 + 按需放大（发现问题后对该会话群提采样率）。

回答按「采样设定依据 → 分层采样与权重修正 → 按数据类型差异化采样」组织，核心是「采样必须有修正机制与类型差异化」，避免为省成本牺牲统计有效性。

• 长期存储的分层：热数据、温数据、冷数据
• 降采样：时间维度的聚合（原始 → 分钟 → 小时 → 天）
• 查询需求与存储成本的平衡

长期存储的分层策略：热存储（近几天）保存原始事件，支撑明细查询与问题回溯；温存储（数周-数月）保存聚合后的分钟/小时级序列；冷存储（数年）只保留天级聚合与摘要（满足趋势对比、审计与合规），各层用不同的存储引擎与成本策略（热层高性能、冷层低成本对象存储）。降采样是「数据进入长期层时做时间维度聚合」：原始点按固定粒度（如 5 分钟窗口）聚合成计数/分位数摘要（avg、p50/p95、count、error 率），丢弃明细，序列长度指数级缩小；聚合本身可以保留分布信息（用 t-digest 等紧凑分位数结构），使降采样后仍能回答「P95 是多少」。要点：降采样粒度按数据特征分档（高波动指标用更细粒度）；降采样前确认「明细查询窗口」需求（问题排查需要近 N 天原始数据）；冷数据可再压缩与去重；合规保留期（如个保法要求的删除机制）约束冷层生命周期。

回答按「分层存储（热/温/冷）→ 降采样聚合（时间维度 + 分位数摘要）→ 查询需求平衡」组织，核心是「存储分层决定降采样时机，降采样保留统计信息而非简单丢点」。

• 合规约束：个人信息收集的授权、最小化与删除权
• 技术合规手段：脱敏、去标识化、数据驻留与同意管理
• 监控数据的分级与合规设计

约束要点：监控收集的数据（设备标识、IP、浏览行为、页面内容）可能构成个人信息，需满足「告知同意」（清晰告知收集内容与用途、提供拒绝/撤回通道）、「最小化」（只收集业务必需字段）、「删除权」（用户要求删除其数据）、「目的限制」（不得挪作他用）等要求。技术合规手段：脱敏——上报链路对敏感字段（手机号、邮箱、输入内容）做脱敏或不上报；去标识化——用假名/哈希替代可识别标识（设备 ID、用户 ID），降低数据敏感度；数据驻留——按用户所属区域存储（欧盟数据存欧盟），满足数据出境限制；同意管理——监控 SDK 遵守 cookie/consent 横幅的同意状态，未同意时降级为不采集或匿名聚合。工程化：监控数据按敏感度分级（事件名、URL、DOM 内容、输入值），建立字段级采集白名单与审计，隐私变更纳入发布评审；会话回放等强敏感功能默认关闭并在启用时显式告知。

回答按「义务（同意、最小化、删除、目的限制）→ 技术手段（脱敏、去标识、驻留、同意管理）→ 工程化（分级白名单、审计评审）」组织，体现合规从「法务条款」落到「采集链路设计」的落地路径。

• 零信任原则：链路加密、双向认证、最小权限
• mTLS：双向证书认证的机制与作用
• 证书管理与轮换、身份绑定与审计

零信任通信的核心是「默认不信任任何请求，身份与授权逐请求验证」：边缘函数到中心服务的链路上，除 TLS 加密外还要双向认证（mTLS）——客户端（边缘函数）持有自己的证书，服务端验证客户端证书确认「请求确实来自可信的边缘身份」，防止伪造来源与中间人；配合最小权限：每个边缘函数用独立的服务身份（证书/令牌），只授权其需要的调用范围，隔离租户与函数间的越权。工程要点：证书管理——证书由平台签发、注入边缘运行环境（函数不可见明文私钥），生命周期短（自动轮换，如数小时-数天），轮换期间新旧证书并存平滑切换；身份绑定——证书与函数身份绑定并透传到下游（调用链中保留调用方身份），便于审计；降级策略——mTLS 链路异常时宁可拒绝也不明文回退。与 JWT 等应用层凭证结合：mTLS 解决「传输与节点身份」，JWT/权限令牌解决「调用者授权」，两层叠加构成完整零信任。

回答按「零信任原则 → mTLS 双向认证机制 → 证书管理与轮换、身份透传与审计」组织，最后点明 mTLS 与授权凭证的分工（传输身份 vs 调用授权），体现分层信任模型。

• 敏感数据泄露路径：输入内容、页面文本、DOM 属性
• 脱敏手段：输入框遮蔽、DOM 擦除/替换、字段级遮罩
• 录制策略：默认关闭、动态启停与审计

会话回放完整录制 DOM 变化，敏感信息（密码、身份证、聊天内容、金额）会被一帧帧记录下来，脱敏是隐私治理的核心。手段分三层：输入框遮蔽——对 input[type=password]、敏感字段（手机号、身份证、金额）默认遮蔽输入内容（录制占位符而非真实字符），用户主动聚焦时才临时可见（本地预览不落录制）；DOM 擦除——对包含敏感数据的节点（聊天列表、详情卡片）在录制数据中擦除或替换（用同尺寸占位块），可用 CSS 类名/数据属性声明敏感区域（如 [data-mask]），录制器按声明处理；字段级遮罩——需要保留交互轨迹但隐藏内容时，用掩码值（138****0000）替换。录制策略：默认关闭敏感应用/页面的回放（或默认全遮蔽，按需放行）；动态启停——检测到敏感场景（打开支付页、输入聚焦）时暂停录制或切遮蔽；数据访问治理——回放数据加密存储、按角色授权查看、访问审计留痕；并定期扫描录制数据确认无泄露。

回答按「泄露路径 → 三层脱敏（输入遮蔽、DOM 擦除、字段遮罩）→ 录制策略（默认关闭、动态启停、访问审计）」组织，核心是「脱敏是录制器的默认能力而非事后补救」。