HTML二维码不必用JavaScript动态生成；纯静态HTML可通过预生成的图片文件或Base64 data URI实现，关键在于资源是否构建时确定。
HTML二维码必须用JavaScript动态生成吗
不需要。纯静态HTML也能显示二维码，但前提是二维码图片本身是预先生成好的文件或Base64数据URI——也就是说，src 指向的是一个确定的、已存在的图像资源。
常见误区是以为 <img src="qrcode.png"> 就算“静态”，但若这个 qrcode.png 是后端每次请求都重新生成的（比如 /api/qrcode?text=abc），那它在语义上仍是动态的，只是HTML标签没写JS而已。
- 真正静态：二维码图像是构建时就写死的 Base64 字符串，例如
<img src="data:image/png;base64,iVBOR..."> - 伪静态：HTML里写死
<img src="/static/qrcode-20240510.png">，但该文件由CI/CD流程提前生成 - 动态：依赖运行时JS调用
qrcode.js的QRCode.toCanvas()或后端API实时渲染
用qrcode.js生成二维码时，canvas和img输出的区别
两者都属于动态生成，但渲染路径和控制粒度不同：toCanvas() 直接画到页面上的 <canvas> 元素，而 toDataURL() 返回Base64字符串再赋给 <img> 的 src，本质是创建新图像节点。
关键差异不在“是否动态”，而在可操作性和兼容性：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
toCanvas()支持后续像素级操作（比如叠加logo、改颜色），但IE11及以下不支持canvas.toBlob()，导出可能失败 -
toDataURL()兼容性更好，但返回的Base64字符串过长时，某些旧版iOS Safari会截断或报错RangeError: Maximum call stack size exceeded - 如果二维码内容含中文或特殊符号，务必先
encodeURIComponent(text)再传入，否则qrcode.js可能静默失败或生成乱码
如何让动态生成的二维码更快被用户看到
核心不是“加速生成”，而是减少阻塞和提升感知速度。二维码生成本身很快（毫秒级），慢通常出在资源加载或重绘时机上。
- 避免在
window.onload之后才初始化——改用DOMContentLoaded或直接放在<body>底部 script 中 - 不要等整个二维码DOM结构渲染完再调用
QRCode.toCanvas()，确保目标<canvas>已存在且尺寸明确（宽高设为具体像素值，别用%或auto） - 若需响应式尺寸，先计算好 canvas 宽高再设置，再调用生成，而不是靠CSS缩放 canvas 元素——后者会导致二维码模糊且扫码失败
- 对同一页面多个二维码，复用同一个
QRCode实例并调用clear()+makeCode()，比反复 new 更轻量
服务端生成二维码反而更稳？什么情况下该切过去
当你的二维码内容固定、更新频率低（如店铺收款码）、或客户端环境不可控（IoT设备、微信内置浏览器老版本）时，服务端生成更可靠。
典型做法是把文本发给后端接口，返回一个带缓存头的PNG URL，例如 /qrcode?text=https%3A%2F%2Fexample.com%2Forder%2F123&size=300，前端只管 <img src="...">。
- 优势：规避JS执行环境差异、内存限制、CSP策略拦截
data:URI 等问题 - 注意点：URL长度不能超浏览器限制（尤其IE ≤ 2083字符），所以复杂参数建议用POST或短链中转
- 缓存很关键——加上
Cache-Control: public, max-age=31536000，避免重复请求；若内容可能变更，用内容哈希做文件名，比如q-<code>sha256(text).png
动态生成不是银弹，稳定性和可调试性往往比“纯前端”更有实际价值。特别是当用户反馈扫码失败却无法复现时，先检查是不是 canvas 像素被CSS拉伸、或 base64 被截断——这些细节比选哪个库更容易卡住上线节奏。
