V8Log Forensics：面向隐私验证的运行时证据
在授权验证中采集本地 V8Log 证据，用 API 过滤保持 trace 可读，并把每次运行与基线对比，为发布和支持决策提供事实依据。
隐私复核常常止步于一个截图回答不了的问题：页面加载了，流程走完了，profile 看起来也对，但没人能说清这个页面究竟向浏览器要了什么。网络日志显示请求，控制台显示应用自己选择打印的内容，两者都没有描述隐私负责人真正要负责的浏览器行为。
V8Log 在你本来就要跑的这次会话里给出答案。它在一次短的授权验证会话中把浏览器运行时活动写入本地 JSONL 文件，让发布负责人复核实际发生了什么，而不是推测大概发生了什么。
一次验证会话需要证明什么
先想清楚证据要支撑哪个决定。隐私负责人需要知道这次会话是否与所选 profile 保持一致。QA 负责人需要知道浏览器变更有没有改变页面观察到的内容。支持工程师需要判断客户反馈属于 profile 配置、网络路由、自动化行为，还是页面本身。
这三个人需要同一份底层记录和不同的摘要。记录要足够具体，能区分成因；也要足够概括，可以在发布会议上讨论，而不会变成实现细节评审。
一次有效的会话回答四个运维问题：页面触碰了哪些大类信号族；观察到的活动是否与本应生效的 profile 和版本一致；浏览器更新、profile 变更或自动化调整有没有让这些活动发生位移；材料是否足以指定负责人。
在开跑之前先把问题写下来。没有问题就采集的 trace，最后是一个没人读的文件；带着明确问题采集的 trace，通常一轮复核就能结案。
静态阅读代码到哪里失效
先读页面代码是自然的第一步，直到页面不再可读为止。生产页面会发打包过的 bundle、VM 风格解释器和 WebAssembly 模块，第三方脚本还会继续加载更多第三方脚本，远端配置也会让同一个 URL 两次加载表现不同。
到这一步，静态阅读变得又慢又贵，而且仍然留有缺口。评审可以在一个 bundle 上花掉一天，却依然说不出某个分支在客户真实流程里到底有没有执行。
运行时证据把问题从"这段代码可能做什么"换成"这次会话做了什么"。后者更小、更可判定，而且正是发布决定所依赖的那个问题。
它的扩展方式也不同。静态阅读的工作量随 bundle 体积和混淆程度增长；运行时记录的体积随流程长度增长，而流程长度由团队通过保持复现简短来控制。
记录的是运行，不是页面
V8Log 是会话级模式。除非某次运行主动要求，否则它不开启；正式版中的使用还受 profile 权限和构建策略约束。这个约束在实践中很重要：一个可能被忘记关掉的验证模式，会在有人注意到之前就先变成存储问题。
证据的单位是运行，不是 URL。同一个页面用两个不同 profile 跑出来的是两份不同证据，二者对比往往就是整个复核。请把浏览器版本、profile 包、路由策略、trace 模式和流程版本与 JSONL 文件一起保存。缺了这些上下文，trace 只是一个没有挂任何结论的文件。
复现要短。打开页面、执行能复现该行为的步骤、行为一出现就结束会话。冗长的探索式会话只会得到更大的文件和更弱的论证，因为事后没人分得清哪一段才是关键。
文件命名要让复核者几个月后还能找到：case 编号、日期、profile 家族、浏览器版本就够了。存储纪律不是形式主义，trace 的价值就在于日后出现分歧时还能被重新读一遍。
选一个读得完的 trace 深度
V8Log 有三档设置，选哪一档是真正的判断，不是随手用默认值。
none 是常态。不记录任何内容，正常浏览行为不受影响。
sample 是多数复现的工作档。它产出精简 trace，小到可以人工通读，细到足以把活动归入信号族。
full 用于精简视图留下明确疑问、且复现很短并有人引导的场景。把它当作第二次尝试而不是第一次，因为在复杂页面上文件体积增长很快。
--bot-v8-log=sample
--bot-v8-log-dir=/tmp/botbrowser-v8log
常见的失败不是细节不足，而是文件大到复核者根本读不完，case 就此停摆。先用小档，只有当复核确实有一个精简 trace 答不了的具体问题时再往上加。
把所选档位写进 case 记录。两次运行只有在同一深度下对比才有意义，而这个细节在两次会话之间最容易丢。
把高频 API 挪开
关于运行时证据，最常见的抱怨是量。一个页面把某几个字符串或数组操作调用几万次，就足以把真正要看的活动埋掉，有价值的调用被挤到没人读得到的位置。
--bot-v8-log-exclude-api 直接解决这一点。传入逗号分隔的精确 API 名，这些调用就不会进入 trace：
--bot-v8-log=full
--bot-v8-log-exclude-api=String.charCodeAt,Array.join
名称按精确匹配，名称前后的空白会被忽略。被排除的调用不会写入，也不消耗 trace 的事件预算，因此它们本会占用的空间留给了正在复核的活动。其他 API 仍然保留，没有 API 名的事件也保留。该过滤在 V8Log 启用且当前 profile 支持时生效。
把排除清单当作复核工具，而不是事后清理。从一份 full trace 里移掉两个已知的高频操作，复核者往往就能在自己想要的深度上拿到可读文件，而不必退回精简档、丢掉当初升档要看的细节。
排除清单要与本次运行一起记录。带着未记录过滤的 trace，可能让下一位复核者得出"这个页面从未触碰过某项"的结论，而它只是被过滤掉了。这种错误代价很高，因为它看起来像发现，其实是缺口。
清单要短、要具体。凭大致印象大范围过滤会让整件事失去证据价值，而在一个页面上合理的排除，换一个页面可能正好挡住关键调用。
按上下文划定证据范围
并发的验证会话很少需要同一个证据范围。一个上下文可能在结算流程上复现客户反馈，另一个在登录页做例行发布检查；给两者套同一份过滤清单，至少有一边的 trace 是错的。
每个浏览器上下文可以带自己的排除清单，范围跟着复核走而不是跟着会话走。定向复现保持窄，面上检查保持宽，两者不必错开时间运行。
这与已有的 per-context 身份能力是同一套思路。上下文有自己的 profile 归属、自己的路由和自己的存储，再加上自己的证据范围，就可以在 case 记录里作为一个完整单元来描述。
请在文件名或 case 记录中标明上下文。如果同一次会话的两份 trace 到了复核者手里却分不清出自哪个上下文，当初驱动这次运行的对比就没法做了。
建立对比基线
单独一份 trace 只描述一次运行，说不出这次运行是否正常。与已存基线对比，才是复核产出决定的地方。
挑一组能代表该部署的少量流程：登录、搜索、结算、加载面板、创建账号、播放媒体。选部署真正依赖的，不是最好写脚本的。
用已接受的浏览器版本和已批准的 profile 各跑一遍，把结果存为基准。后续每次运行都要对着它读，因此它值得与其他发布产物同样的照料。
这组流程要短到每个候选版本都跑得起来。一组每次都用的小集合，胜过排期一紧就跳过的大清单。当真实用户路径变化、支持 case 暴露缺口，或某次更新触及负责人关心的面时，再往里加流程。
更新基线要有意为之。应用有意改变行为时，更新基准并写明原因。悄悄漂移的基线会让之后每一次对比都变成"哪次运行才对"的争论。
浏览器或 profile 变更后重跑
对比的价值体现在变更边界上。浏览器版本、profile 包更新、自动化框架变更、主机镜像变更，每一项都是重跑既有流程并对比的理由。
排期允许时一次只改一个组件。把浏览器升级、新 profile 和应用发布混在一次运行里，得到的差异没人能归属，复核只能以猜测收场。
先在信号族层面读对比结果。页面触碰的信号族发生位移，通常比调用次数变化更有信息量，也更容易落到具体负责人身上。次数放在第二步读，此时信号族视图已经把问题收窄。
不是每个差异都是问题。页面会变，第三方脚本会变，远端配置不发版也会变。对比的产出是判断该差异是否在预期内，而不是自动拦版。
把判断结论与证据一起记录。下一位复核者需要知道某个差异已经被看过并接受，否则每次发布都会重新查一遍。
用证据分派支持 case
支持分诊是回报最快的场景。客户反馈通常只有一张截图加一句话，没有运行时证据的话，最初几个小时都花在判断该由哪个团队接手。
一次简短的 V8Log 复现能很快收窄范围。证据能把 profile 配置问题与网络路由问题分开，把自动化行为与页面行为分开，而这几类各有各的负责人和修法。
复现要留在与客户约定的范围内，使用测试账号和已批准页面。超出约定采集到的证据，无论显示了什么，在这个 case 里都不可用。
把 trace 连同上下文记录一起附到 case 上。支持 case 会在不同人之间流转，第二位工程师需要在不请客户重跑的前提下知道文件出自哪个版本和哪个 profile。
结案时闭环。一个带着已存 trace 和明确成因的已结 case，会成为下一个类似反馈的参照，分诊时间才会随发布周期下降，而不是一直原地踏步。
证据留在自己的环境里
V8Log 写的是本地 JSONL 文件。它们留在产生它们的环境中，正是这一点让该模式在隐私敏感部署中可用。
把这些文件当作敏感材料。真实流程的 trace 反映的是一次真实会话，应受与其他会话证据相同的访问约束：与 case 一同存放，限制可读范围，套用组织对同类记录的留存策略。
每次运行都优先使用测试账号和已批准页面。这样证据对复核仍然有用，客户材料也不会进入将被附到内部 case 的文件。
在开 case 时就定好留存期限，而不是等存储写满再定。trace 在一个发布周期里累积得很快，事先约好的规则比临时压力下拍板的规则容易执行。
明确什么结果算通过
证据流程需要写明的通过条件，否则每个复核者各按私人标准判断，结果就失去可比性。
条件要写成发布负责人能确认的形式：流程走完了用户可见的各步；观察到的信号族与该流程的既存基准一致；与基准的差异都经过复核并给出了解释；记录中的浏览器版本、profile、路由策略和 trace 设置与将要上线的一致。
失败条件也要写。跑不完的运行、采不到的 trace、没人能解释的差异，各自都应导向一个有记录的处理动作，而不是聊天里再要一个意见。
把隐私层面的拦版与性能偏好分开。全量 trace 下跑得更慢不是隐私发现，跑得快也不构成一致性证据。两类判断要分开，谁都不能悄悄压过谁。
指明谁可以批准例外。紧急发布确实存在，有记录的审批路径能让例外事后仍可复核，而不是变成没有留痕的先例。
指定负责人与复审日期
每个既存流程都需要一个能判断差异是否重要的负责人。否则对比只会产出在各处流转、始终没有结论的发现。
负责人负责让流程跟上应用变化、在变更是有意的时候更新基准、并记录发布判断。这个角色通常属于拥有该客户路径的团队，而不是运行浏览器的团队。
给流程集合本身定一个复审日期。应用变化的速度快于验证方案，与产品已经对不上的基准，产出的差异说的是方案而不是这次发布。
记录要让复核之外的人也读得懂。隐私、支持和基础设施都会读它，任何一方都不应为了跟上结论而去打开原始 trace。
批准前要回答的问题
什么时候该用 V8Log。 当验证或支持问题涉及某个具体流程中的浏览器运行时行为，而静态阅读页面已经给不出答案时。
第一次跑用哪个档位。 从 sample 开始。只有当精简 trace 留下明确疑问时才升到 full，并把那次运行保持简短。
排除清单里放什么。 与本次复核无关的高频操作的精确名称，并与运行一起记录，好让下一位复核者知道过滤掉了什么。
复现应该多长。 在能复现行为的前提下越短越好：打开页面、执行步骤、结束会话。
什么样的对比才可信。 两次运行使用同一流程版本、同一 trace 深度、同一排除清单，并且浏览器版本和 profile 都有记录。
结果由谁负责。 被验证客户路径的负责人，证据附在发布记录或支持记录上。