前端A/B测试核心是用户变体固化与单模板动态渲染：优先用localStorage存取variant，配置驱动表单生成，FormData统一取值，埋点基于DOM属性而非JS变量，SSR需服务端首屏注入并校验。
前端做 HTML 页面 A/B 测试，核心不是“能不能写两套 HTML”，而是“怎么让同一用户稳定看到同一版本，且后端不改、埋点不乱、校验不崩”。自己手写比用工具更可控，也更容易踩坑。
怎么固化用户变体（避免刷新后变脸）
每次 Math.random() 分流，会导致用户刷新后看到另一个版本——提交中断、数据归因错乱。必须固化分配结果。
- 优先读
localStorage.getItem('form_variant')，有值就直接用 - 没值时才随机选
'a'或'b'，然后存进localStorage（低版本可 fallback 到document.cookie） - 别依赖 URL 参数做主依据——容易被分享、缓存、SEO 抓取，污染变体标识
- 若需服务端协同（如日志打标），把
variant值塞进隐藏字段：<input type="hidden" name="variant" value="a">，但 A 和 B 版本都得有，值不同
怎么只用一份模板渲染 A/B 变体（不写两套 HTML）
硬写两个完整 <form> 模板，后期维护成本爆炸，DOM 冲突、焦点跳转异常、校验逻辑重复等问题会集中爆发。
- 定义统一配置对象，比如
formConfig = { a: { fields: [] }, b: { fields: [] } } - 用一个模板函数
renderForm(variant)动态生成 DOM，字段是否显示、required、defaultValue、placeholder全部来自配置 - B 版新增字段时，只改配置，不改 JS 主逻辑；后端接口必须能接收该字段（允许为空或有默认值）
- 绝对不用
display: none切换版本——两个表单 DOM 同时存在，querySelector('input[required]')会误判，checkValidity()失效
submit 事件里怎么正确取数（别漏字段也别多字段）
手动拼 FormData 或遍历 form.elements 极易出错：disabled 字段不进 FormData，hidden 字段会进，而 A/B 差异常涉及这两类状态。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 一律用
new FormData(formEl)，它只收集当前可见、name非空、未被disabled的控件 - A 和 B 版本所有字段必须共用相同
name属性（如都叫email），否则后端收不到 - 若 B 版某字段设为
disabled，A 版对应字段也得同步处理（比如设成readonly+hiddeninput 补默认值），否则 POST 结构不一致 - 校验逻辑不能写死在
submit里，应基于当前variant动态检查字段有效性
埋点怎么区分 A/B（别靠 JS 变量或 URL）
埋点代码执行时机和取值方式不对，会导致 80% 的 A/B 数据不可信。
- 曝光埋点放在
form.querySelector('form').offsetParent !== null后触发，确保真正可见 - 转化埋点（如成功提交）必须读取运行时表单上的
data-variant="a"属性，而不是初始 JS 变量值（防止异步操作导致状态漂移） - 错误信息里别打日志
"submit failed for variant b"——改成具体字段名，比如"email validation failed in variant b"，方便归因 - 隐私模式下
localStorage不可用，需降级到 URL 参数，但仅作 fallback，不作为主依据
最复杂也最容易被忽略的点是：SSR 场景下，首屏必须由服务端决策并注入 data-variant，前端再读取并校验一致性；否则用户可能看到闪动，或埋点与实际渲染版本错位。
