防伪编码应存于标签中，如，不可用id/class或div/p包裹，须服务端生成签名并校验，前端仅安全呈现。
防伪编码不是靠 HTML 标签“标注”出来的，HTML 本身不提供防伪能力；它只是把已生成的唯一 ID 展示给用户看。真防伪得靠后端生成、签名、校验，前端只负责安全地呈现。
防伪编码该存在哪个 HTML 元素里
用 <meta> 标签放最稳妥，比如塞进 里的 <meta name="cert-id" content="ABC123...">。这样既不干扰页面视觉，又方便自动化工具（如验证脚本、爬虫、审计系统）精准提取，还不容易被误删或覆盖。
别用 <div> 或 <code><p></p> 直接包裹编码——用户复制时可能多带空格、换行或前后文字；也别藏在 data- 属性里（如 data-cert-id），部分老旧爬虫或校验工具不识别自定义属性。
- 必须确保
content值是纯字符串，不含 HTML 实体（如不用隐形字符混淆） - 避免把编码拼在 URL 参数或 JS 变量里展示，那属于运行时动态内容，无法被静态校验工具读取
- 如果证书要打印，记得在
@media print里显式显示该<meta>的对应提示文案（比如用<span class="print-only"></span>）
id 属性不能当防伪编码用
id 是 DOM 标识符，不是业务凭证。它可被前端任意修改、重复、删除，浏览器也不校验其唯一性或格式。把防伪码硬塞进 <div id="CERT-2024-789">，等于把密码写在门牌号上——看着像那么回事，其实毫无约束力。<p><span>立即学习</span>“<a href="https://pan.quark.cn/s/cb6835dc7db1" style="text-decoration: underline !important; color: blue; font-weight: bolder;" rel="nofollow" target="_blank">前端免费学习笔记（深入）</a>”；</p>
<p>更麻烦的是：一旦页面有多个证书模块，<code>id 重复会触发 HTML 合法性警告，某些严格解析器（如 XML 工具、无障碍检测器）直接报错；而防伪系统依赖的往往是精确匹配，ID 一乱就全崩。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 绝对不要用
id或class存编码值 - 即使你控制全部前端代码，也不能假设用户不会右键审查元素后手动改掉
id - 如果要用 DOM 定位展示区域，用独立的容器
id（如id="cert-display"），编码本身走<meta>或隐藏<input>
怎么让防伪编码不被轻易批量抓取
做不到完全防抓，但可以提高门槛。核心思路是：不让编码以明文、固定位置、可预测结构暴露在 HTML 源码里。
常见错误是把所有证书都用相同 name 的 <meta>，比如统一叫 cert-id，结果一个正则 <meta>]*name="cert-id"[^>]*content="([^"]*)"[^>]*/> 就全薅走。稍微改下策略就能卡住大部分脚本：
- 用动态
name值，比如name="cid-{{hash(cert_no)[:6]}}"，每次渲染不同 - 把编码拆成两段，一段放
<meta>，一段放<script></script>内联变量，验证时需拼接（注意 XSS 过滤） - 对编码做简单不可逆混淆，比如 Base64 + 固定位移，不为加密，只为打破正则通用性
记住：这些只是增加自动化采集成本，不是替代服务端签名。真正校验仍需用户访问官方验证页，传入编码并由后端比对签名、时效、状态。
最常被忽略的一点：防伪编码的生成和绑定必须发生在服务端，且与用户身份、发证时间、证书哈希强关联。前端哪怕把编码用 canvas 渲染成图片、用 SVG 路径描边、甚至藏在字体文件里，只要没服务端校验环节，就只是纸糊的锁。
