公众号带参数二维码的“参数”不是靠图片上传到自己的接口，而是在创建二维码时指定场景，再在平台事件中取回。2018 年做扫码统计时，我最初一直在找查询扫描次数的接口，后来才理清这个事件推送关系。

先创建场景，再取得二维码

旧流程分两步：调用创建接口取得 ticket，再凭 ticket 获取二维码图片。下面是临时整型场景的请求体结构：

{
  "expire_seconds": 600,
  "action_name": "QR_SCENE",
  "action_info": {
    "scene": { "scene_id": 123 }
  }
}

字符串场景使用另一类 action_name 和字段：

{
  "expire_seconds": 600,
  "action_name": "QR_STR_SCENE",
  "action_info": {
    "scene": { "scene_str": "campaign-demo" }
  }
}

场景值由开发者定义，用于关联渠道或业务记录。永久类型在旧协议中使用 QR_LIMIT_SCENE、QR_LIMIT_STR_SCENE；有效期、数量和字段限制应以账号对应的当前文档为准，不沿用旧笔记中的限额作为今天的承诺。带参数二维码文档入口

ticket 与业务 scene 是不同对象。旧流程的 showqrcode 请求把 ticket 作为参数，需正确 URL 编码；不能拿 scene_id 直接替换 ticket，也不应公开实际绑定业务的临时票据。

事件不是自己轮询出来的

旧明文接入中，GET 用于配置地址验证，POST 用于接收平台消息和事件。扫码相关事件也发送到配置的接收地址，但不是所有 POST 都是扫码，必须解析消息类型和事件类型。

对于历史的场景二维码流程，需要区分：

用户及动作事件与场景线索
未关注用户扫码后关注subscribe 事件，EventKey 中可能带 qrscene_ 前缀
已关注用户扫描场景码SCAN 事件，EventKey 表示相应场景
普通关注、其他事件不应默认当作场景扫码

场景创建时叫 scene_id 或 scene_str，事件里却通过 EventKey 等字段表达，这是原项目最容易混淆的地方。普通二维码也可以编码 URL；这里讨论的是公众号平台的场景事件能力，不能说“普通二维码无法传递任何参数”。

统计口径由业务定义

收到一次事件，不一定等于一个独立用户，也不一定能证明一次真实转化。网络重试可能造成重复推送；同一用户也可能多次扫描。应先验签、按所用模式解密，再定义去重、事件次数、人数及渠道归因口径。

做账号绑定时，场景应有有效期并绑定待确认的业务会话，不能只凭可猜测的数字就完成绑定。服务器接入与权限排查见回调验证和事件接收。