为什么要这么写：qrcode库默认参数会生成超大图片，导致传输慢

import qrcode
from qrcode.image.styledpil import StyledPilImage
from qrcode.image.styles.moduledrawers import RoundedModuleDrawer

def fast_qr_generator(data, size=10):
qr = qrcode.QRCode(
version=1, # 版本1=21x21矩阵，生成最快
error_correction=qrcode.constants.ERROR_CORRECT_M, # 15%纠错，够用
box_size=size,
border=2, # 默认4，改成2省了30%的尺寸
)
qr.add_data(data)
qr.make(fit=True)

• 版本1（21×21）：0.8秒
• 版本5（37×37）：1.5秒
• 版本10（57×57）：3.8秒

场景1：电商商品链接二维码

这是最基础的应用，但坑在二维码有效期。我们有个客户把商品二维码印在包装上，结果三个月后链接失效了，用户全来投诉。解决方案是用动态二维码——二维码图案不变，后台随时改跳转链接。

const app = express();

// 动态二维码生成接口
app.post('/api/dynamic-qr', async (req, res) => {
const { productId, redirectUrl } = req.body;

// 存储映射关系到数据库
await db.saveRedirect(productId, redirectUrl);

const qrSvg = await QRCode.toString(qrContent, {
type: 'svg',
width: 200,
margin: 2,
color: {
dark: '#000000',
light: '#ffffff'
}
});

另一个坑是二维码尺寸。印在商品包装上至少需要2cm×2cm，太小了手机扫不到。我们测试过不同尺寸的扫码成功率：

• 1cm×1cm：扫码成功率仅45%，用户反馈"扫不出来"
• 1.5cm×1.5cm：78%
• 2cm×2cm：96%

场景2：活动现场签到二维码

这是我在给客户做线下活动时踩的最惨的坑。活动当天3000人同时扫码，结果系统直接挂了——高峰期并发请求达到了2000/秒。

解决方案是预生成+CDN缓存。提前把所有参会者的二维码生成好，存到CDN上，活动当天直接从CDN加载。

为什么要这么写：预生成避免运行时计算压力

import hashlib
import os
from concurrent.futures import ThreadPoolExecutor

def batch_generate_qr(attendees: list):
"""批量预生成二维码，每个参会者一个唯一码"""

def generate_single(attendee):
# 用参会者ID+活动ID生成唯一内容
content = f"event:2024-summer|uid:{attendee['id']}|checkin:{attendee['checkin_code']}"

# 生成文件路径：按日期分文件夹
date_dir = datetime.now().strftime("%Y%m%d")
os.makedirs(f"cdn/qr/{date_dir}", exist_ok=True)

filename = hashlib.md5(content.encode()).hexdigest()[:16]
filepath = f"cdn/qr/{date_dir}/{filename}.png"

# 如果已经存在就不重复生成
if not os.path.exists(filepath):
img = fast_qr_generator(content, size=15)
img.save(filepath)

return f"https://cdn.ourdomain.com/qr/{date_dir}/{filename}.png"

with ThreadPoolExecutor(max_workers=10) as executor:
results = list(executor.map(generate_single, attendees))

预生成方案上线后，活动当天的服务器负载从95%降到了12%，用户扫码后2秒内完成签到。

核心：一张对比图展示预生成方案和实时生成的性能差异（响应时间和服务器负载）

场景3：WiFi密码二维码

正确的格式是：

参数解释：

场景4：电子名片二维码

很多工具生成的二维码，扫码后显示的是丑到爆的HTML页面。我用过的专业方案是基于vCard格式：

iOS和Android原生都支持这种格式，扫码后直接弹出"添加到通讯录"的提示，体验好太多。

场景5：支付二维码

这是最敏感的场景，坑最多。首先是安全风险：如果二维码被篡改，用户的钱可能转给黑客。

生产环境一定要用带签名的二维码：

为什么要这么写：防止二维码被篡改，加签名验证

import hmac
import hashlib
import base64

def generate_secure_payment_qr(order_id, amount, merchant_id):
# 构建支付数据
payment_data = {
"order_id": order_id,
"amount": amount,
"merchant_id": merchant_id,
"timestamp": int(time.time())
}

# 用HMAC-SHA256签名
secret_key = os.environ.get("PAYMENT_SECRET_KEY")
message = f"{order_id}|{amount}|{merchant_id}|{payment_data['timestamp']}"
signature = hmac.new(
secret_key.encode(),
message.encode(),
hashlib.sha256
).hexdigest()[:16] # 截取前16位作为签名

payment_data["signature"] = signature

支付二维码还有一个坑：金额显示。很多用户扫码后看到金额不对会退款，所以二维码里要编码金额信息，让支付App自动填充。

场景6：会议签到二维码（含座位号）

这是场景2的升级版，需要把座位信息也编码进去。我设计的方案是：

这样扫码后不仅完成签到，还能显示座位指引。但注意内容不要超过4296个字符（二维码的最大容量），否则会生成多个二维码。

场景7：文档/文件分享二维码

很多人在用百度网盘分享链接生成二维码，但有个致命问题：链接会过期。我推荐的做法是用自建对象存储，设置长期有效的访问链接。

还有一个实用技巧：二维码里可以编码文件名和大小，这样扫码后显示"即将下载《项目报告.pdf》(2.3MB)"，用户体验更好。

场景8：地图定位二维码

这个场景适合线下店铺引流。二维码内容格式：

iOS和Android原生地图都支持这个协议。但坑在坐标精度：我试过用百度坐标，结果在苹果地图上偏了500米。一定要用WGS-84标准坐标（GPS坐标），百度/高德的坐标需要转换。

场景9：多语言内容二维码

如果目标用户是多国用户，二维码里可以编码语言参数。比如：

扫码后根据用户手机语言自动跳转到对应语言页面。但注意：动态二维码服务端需要做语言检测，否则千篇一律跳中文。

场景10：小程序跳转二维码

• 每个小程序每天最多生成10万张
• 页面路径必须是已发布的
• 参数长度限制32个字符

为什么要这么写：微信接口有调用次数限制，必须缓存

import requests
import redis

def get_miniprogram_qr(page, scene):
cache_key = f"wx_qr:{page}:{scene}"
cached = redis.get(cache_key)
if cached:
return cached

# 调用微信接口
access_token = get_access_token()
url = f"https://api.weixin.qq.com/wxa/getwxacodeunlimit?access_token={access_token}"

response = requests.post(url, json={
"page": page,
"scene": scene,
"check_path": False,
"env_version": "release"
})

# 微信返回的是二进制图片数据
qr_data = response.content

这个接口的设计真的反人类：返回的二进制数据你得自己转成图片，而且不告诉你图片格式，我一开始还以为是PNG，结果是JPEG。文档里也完全没提。

总结前：一个对比表格展示10个场景的推荐工具、生成方式和注意事项

总结一下，你可以立刻用的三个点