能，但仅限静态内容；纯HTML需用<img>引入预生成二维码图片，零JS且无运行时开销，适用于内容固定场景。
HTML二维码能不依赖JavaScript动态生成吗
能，但仅限静态内容。纯HTML本身没有生成二维码的能力，所谓“不依赖动态生成”，实际是把二维码当普通图片用——提前用工具生成好，再用 <img> 标签引入。这种方式零JS、零运行时开销，适合二维码内容确定且长期不变的场景，比如印刷物料上的网站入口、固定活动页链接。
常见错误是误以为写个 <img src="qrcode.png"> 就算“HTML原生支持”，其实只是借用了HTML加载图片的能力，二维码本身仍是外部生成的。
用 qrcode.js 动态生成时最常踩的坑
主流库如 qrcode.js 或 qr-code-generator 都需在DOM就绪后调用，否则目标容器不存在会导致静默失败。
- 没等
DOMContentLoaded就执行QRCode.toCanvas()，结果canvas空白 - 传入的文本含中文或特殊符号，但没设
type: 'byte'或没指定ECLevel，导致扫码失败 - 用
toDataURL()后直接赋给<img src>，却忘了处理跨域：如果页面启用了CSP策略或部署在file://协议下，base64数据可能被拦截 - 在React/Vue等框架里直接操作DOM生成，未配合生命周期（如useEffect或mounted），造成重复渲染或内存泄漏
QRCode.toString() 和 toCanvas() 性能差异明显吗
差异主要体现在使用方式和输出形态，而非计算耗时。两者底层都调用同一套编码逻辑，生成时间基本一致。
立即学习“前端免费学习笔记（深入）”；
QRCode.toString() 输出ASCII字符组成的文本二维码（适合CLI、日志调试），体积小、无渲染开销；toCanvas() 输出像素级图像，可缩放、可加样式、兼容打印，但需浏览器支持Canvas API。
真实瓶颈不在生成环节，而在后续操作：
- 频繁调用
toCanvas()并插入DOM → 触发重排，卡顿明显 - 用
toString()生成几千行字符再塞进<pre>→ 渲染慢、无法选中链接、手机端扫码体验差 - 未复用
QRCode实例，每次重新初始化 → 多余对象创建，GC压力增大
服务端生成 vs 前端动态生成怎么选
关键看内容是否随用户行为变化。如果二维码要带登录态token、临时订单号、个性化追踪参数，前端动态生成是唯一选择；如果只是公司官网地址，服务端一次生成、CDN分发，更稳定、首屏更快、SEO友好。
容易被忽略的是缓存与更新成本：前端动态生成看似灵活，但每次URL变更都要重新扫码验证；服务端生成虽省心，但改一个字就得重新部署图片资源或加版本号避免缓存。
复杂点在于混合场景——比如用服务端返回一个带签名的短链，再由前端用这个短链生成二维码。这时既要保证签名时效性，又要控制前端生成延迟，得在接口响应时间和二维码可用性之间做取舍。
