最稳方案是用 @xkeshi/qrcode：cdn 引入，调用 tocanvas/tosvg 时指定 width（建议4的倍数）和 margin（≥16），用 colordark/colorlight 控制颜色，响应式需 resizeobserver 动态重绘。
用 qrcode.js 生成 DOM 内嵌二维码最稳
直接操作 canvas 或 svg 生成二维码容易漏掉容错、掩码、版本适配等细节，qrcode.js（官方库 qrcode-generator 的轻量封装）是目前兼容性最好、无依赖、支持 IE11 的选择。它不强制挂载到全局，可按需引入函数：qrcode.generate() 返回 base64 字符串，qrcode.toCanvas() 或 qrcode.toSVG() 直接渲染。
注意：别用 npm 上同名但维护停滞的 qrcode（带 Node.js 依赖），浏览器环境要用 qrcode-generator 或其现代 fork @xkeshi/qrcode —— 后者支持 Promise 和更细粒度配置。
常见错误现象：Uncaught TypeError: qrcode.generate is not a function，大概率是引入了错误包或未正确解构导出。CDN 方式最稳妥：
<script src="https://cdn.jsdelivr.net/npm/@xkeshi/qrcode@1.0.0/dist/qrcode.min.js"></script>
二维码尺寸与 margin 控制靠 width 和 margin 参数，不是 CSS
很多人试图用 transform: scale() 或 width: 200px 强行缩放 canvas 生成的二维码，结果出现锯齿、模块模糊、扫码失败。根本原因是：二维码每个“模块”（module）必须是整数像素宽高，缩放会破坏这个前提。
正确做法是在生成时指定物理尺寸：qrcode.toCanvas(canvasEl, 'https://example.com', { width: 256, margin: 16 })。其中：
-
width是整个二维码图像（含 margin）的像素宽高，建议设为 4 的倍数（如 128/256/512） -
margin是白边宽度（单位像素），默认为 0；值太小会导致扫码器无法识别（尤其微信） - 不要设
scale或errorCorrectionLevel以外的“高级参数”，除非你真需要 L/M/Q/H 级容错
自定义颜色必须用 colorDark 和 colorLight，CSS 滤镜无效
二维码不是普通图片，它的对比度和色阶直接影响扫码成功率。用 filter: invert() 或 background: #ff6b6b 覆盖 canvas 背景，只会让模块边缘发虚或反色失真。
所有主流生成库都提供原生颜色控制：{ colorDark: '#2c3e50', colorLight: '#f8f9fa' }。注意：
-
colorLight必须是纯色（不能是transparent，部分安卓扫码器不认） - 深色模式下避免用纯黑+纯白，改用
#1a1a1a+#f5f5f5更稳妥 - 想加 logo？别覆盖中心区域——先生成带足够 margin 的二维码，再用另一个
canvas绘制 logo，否则扫码率暴跌
响应式二维码要重绘，不能靠 vw 或 max-width
把 canvas 设成 width: 100%; max-width: 300px 看似合理，实际 canvas 内容不会随容器缩放重绘，只是拉伸位图。用户缩放页面或横竖屏切换后，二维码立刻变糊或无法识别。
解决方案只有监听并重绘：window.addEventListener('resize', () => { qrcode.toCanvas(canvasEl, text, opts) })。但频繁触发很浪费，应加节流：
let resizeTimer;<br>window.addEventListener('resize', () => {<br> clearTimeout(resizeTimer);<br> resizeTimer = setTimeout(() => renderQR(), 150);<br>});更优做法是用 ResizeObserver 监听目标容器，只在真正尺寸变化时触发。
复杂点在于：移动端横竖屏切换时，resize 事件可能触发多次且带延迟；而 orientationchange 已废弃。最终建议统一用 ResizeObserver，并确保 opts.width 根据容器当前 clientWidth 动态计算，而不是固定值。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
