iv8：基于 V8 的 C++ 浏览器补环境框架
补环境的本质是对抗检测，靠 JS 层模拟，总会遇到难以彻底复刻的检测点，比如 document.all、跨域/跨 Context 的身份同一性等。
与其在 JS 层疲于奔命地“修修补补”，不如深入 C++ 层，在 V8 之上重筑一套原生的浏览器运行时。iv8 的监控不依赖 JS Proxy，而是通过 V8 回调封装与通用属性拦截器，实现统一的 API 访问追踪。整体架构对齐 Chromium 的 ScriptWrappable/WrapperTypeInfo，并采用基于 v8::Global<> 的强引用方案配合显式释放，避免句柄滞留导致的内存占用累积，同时也避免引入 cppgc 带来的额外复杂度。
本文是一次阶段性总结：把 iv8 的动机、关键设计取舍、踩坑经验与现阶段结论整理出来，方便后续迭代与复用。它不是“完整复刻 Chromium”的承诺，而是一套在真实对抗场景中可落地的工程化探索。部分能力仍遵循“最小可用/先对齐可观测外壳”的策略逐步完善。
目前框架已在 BOSS、瑞树 6、阿里 231 等场景测试通过：BOSS 抗更新稳定采集；瑞树从构建 DOM、执行 3 段 JS、触发 load 事件到产出第二次 Cookie 耗时 40ms左右；阿里 231 配合轨迹算法，10 并发跑 1000 次，100% 通过率。
实测结果（节选）
瑞树 6
阿里 231
整体架构（分层图）
重点能力展开
DevTools 联合调试：从“黑盒跑脚本”到“白盒定位点”
- 内置 Inspector + WebSocket：无需额外依赖，即可接入 Chrome DevTools Protocol，实现断点、调用栈、Scope 变量、Sources 映射等完整链路。
- 多 Context 联动：iframe 的 Context 会被注册到 DevTools，会话内可以直接切换上下文。
反调试：让 debugger; 失效，但保留可控调试入口
- 屏蔽
debugger;：修改v8，让“debugger”变成空操作，语义失效，不再导致 DevTools 不断暂停。 - 新增
vdebugger;：修改v8，注入“vdebugger”，保留一个只在“独立语句形态”触发的自定义断点语句。
console 与 vconsole：调试通道与对抗语义解耦
- 背景：许多站点会把
console当成检测入口，利用 DevTools 的格式化/对象预览展开触发 getter、toString等副作用，用来探测“是否打开 DevTools”或制造可观测差异。 - 策略：修改v8，devtools模式不再注入console，注入自定义“vconsole”，需要调试输出时用
vconsole作为独立通道，把调试与对抗语义解耦。
watch_apis：命中自动触发断点（debugger），快速定位关键调用链
- 解决什么痛点：混淆/动态函数名/eval 很多时，很难定位“到底是谁在读写关键浏览器 API / 关键对象（属性）”，导致逆向排查效率极低。
- 核心价值：启用 DevTools 模式下，把候选 API（含反射入口）加入 watch 列表，一旦命中就自动触发断点（debugger）并暂停；直接从调用栈回溯到“谁在用、在哪用”，比追日志更快，也比手工下断点更稳。
命中：script.getAttribute
统一监控（含反射层）：可观测性是补环境提效的关键
- 方法/访问器监控：记录调用路径、参数、返回值与异常语义，区分“实例访问 vs 原型访问”等。
- 通用属性拦截：覆盖 data property 的读写、缺失点发现，并在常见反射路径上保持语义一致（避免误报/避免破坏原型链行为）。
- 反射层监控：对
Object.keys/getOwnPropertyNames/getOwnPropertySymbols/defineProperty...、Reflect.get/has/ownKeys...、Function.prototype.toString等“高频检测入口”提供监控与（可选的）自动断点。
文档加载流水线：离线快照加载（Chromium-like DocumentLoadPipeline）
- 目标：把“离线跑脚本”做成更接近 Chromium 的加载时序：解析 HTML → 遇到
<script>→ 获取/执行（含 microtasks checkpoint）→ 继续解析，并同步驱动readyState/DOMContentLoaded/load的阶段边界，避免站点依赖加载顺序导致跑不通。 - 输入形态（离线快照）：
baseURL+html，以及可选的外链脚本/样式离线 bundle（无真实网络也能尽量还原“脚本何时执行/样式何时生效”的关键语义）。 - 设计约束：同步、确定性、可回放；不引入后台线程/后台计时器，避免批量跑时出现不可控副作用/漂移。
布局与几何闭环：验证码优先，非真实渲染
- 目标：不做真实渲染，但保证脚本常读的几何 API（
offsetWidth/offsetHeight/getClientRects/getBoundingClientRect）稳定、内部一致、可解释；优先解决滑块/验证码与现代页面“读几何→分支行为→过风控”的关键路径。 - 字体/指纹相关：虚拟字体度量（纯配置/纯算法，不依赖宿主机字体 API），可用
fonts.metrics做多套 profile 切换，覆盖“字体指纹 + 几何闭环”常见检测。 - 布局相关：layout-only CSS + selector/cascade，支持
<style>/<link rel=stylesheet>，外链 CSS 可由离线 bundle 提供给加载流水线消费。
可信输入注入通道（isTrusted=true）
- 语义对齐：JS 标准
EventTarget.dispatchEvent(...)路径强制isTrusted=false（页面脚本无法伪造 trusted 输入），避免破坏浏览器语义。 - 平台层注入：提供 Mouse/Pointer 等输入注入，以及组合级“拖拽”能力（handle + trajectory → down/move/up）
- 与时间/队列联动：轨迹点可携带时间增量，内部推进逻辑时间并按步驱动队列，便于对齐验证码常见的“时序 + 输入”联合检测。
iframe/Worker 隔离：Split Window Model + Worker 独立运行时
- Split Window Model：保证 WindowProxy 身份稳定；iframe 之间 Context 隔离，避免跨 iframe 污染导致“指纹不一致/对象身份不对”这种硬检测。
- Worker 最小可运行环境：提供独立
globalThis/self与最小脚本加载能力（data/blob/file），覆盖站点把签名/风控逻辑丢进 Worker 的常见做法。 - 价值：把“隔离”与“同源一致性”收敛到统一模型，降低跨 Context/跨线程的检测风险与补环境复杂度。
事件循环 + 逻辑时间：让异步与时间变成“可控变量”
- 任务队列机制：宏任务/微任务/定时器等队列分离并可控驱动，解决“Promise/Timer 时序稍有偏差就跑不出结果”的典型问题。
- 逻辑时间推进：不依赖系统时间，通过逻辑推进生成确定性时间戳序列，便于回放/对比，也便于批量跑时保持结果稳定。
环境配置：把“散落的指纹点”收敛成一套可控配置
- 一份 profile 收敛/切换指纹点：用一份“环境配置 / profile”集中管理 UA/UA-CH、语言/时区、平台、字体度量、WebGL 能力、功能暴露面等关键指纹点；跑不同目标站/不同设备画像时只需要切换 profile，而不是到处打补丁。
- 初始化期生效（从启动就一致）：配置在初始化阶段生效，保证脚本从第一行开始读取到的环境一致，避免“先读后改”造成的语义漂移。
- 跨 Context 一致性：主页面与 iframe/Worker 等上下文共享同一画像配置来源，减少跨上下文指纹分叉与可检测漂移。
ScriptOrigin ResourceName：堆栈资源名对齐（过检测 + 可定位）
很多站点会主动触发异常/构造 Error，读取并分析 stack，用“资源名是否符合预期 URL 形态”等信号做检测。iv8 在执行脚本时支持传入 name，把它写入 V8 的 ScriptOrigin(ResourceName)，从而让堆栈里的资源名更接近 Chromium 行为；同时也能让 DevTools 的 Sources/调用栈更可读，便于定位。
未来计划
- 逐步完善框架
- 引入chromium网络栈
