2.4 KiB
2.4 KiB
name, description, type
| name | description | type |
|---|---|---|
| 公众号主体与接口权限现状 | 正式公众号是个人订阅号、未认证、AppSecret 冻结；核心结论「带参数二维码只有已认证服务号可用」，故当前扫码登录流程无法在订阅号上跑通，待用户选路线 A/B | project |
2026-10-10 用户正式注册了微信公众号，AppID wxb4bd18ef8255c03f
（AppID 是公开标识、非密钥，可记录；AppSecret 属敏感值，未认证前处于冻结状态，不入库）。
账号状态
- 类型：订阅号（个人主体，用户没有个体户/营业执照）
- 未完成微信认证；用户正在申请「改名」，改名通过后才做「个人认证」
- AppSecret 冻结：官方提示「该账号尚未完成主体认证，前往微信公众平台完成认证后重试」
→ 拿不到
access_token
决定性结论（已查证微信官方开放社区，2026-10-10）
- 「生成带参数的二维码」接口只有「已完成微信认证的服务号」可用；认证订阅号、 个人订阅号均不可用。
- 因此 换到该订阅号跑不通当前扫码登录流程；改名 + 个人认证也解决不了（仍是订阅号）。
- 未认证个人订阅号可以用「服务器配置 + 接收消息 + 被动回复」（不需要 AppSecret）， 但开启服务器配置后就不能同时用后台自定义菜单（对本项目无影响）。
可选路线（待用户拍板）
- A（推荐，符合原设计）：办个体户 → 注册「服务号」→ 微信认证 300 元/年。 保留「扫码即授权、用户免手输」体验，并解锁阶段 3 微信支付（支付同样要求认证服务号）。
- B（不办个体户，但要改代码）：改造登录流程绕开带参数二维码 ——
MFC 显示随机验证码 → 用户关注公众号后把验证码发给公众号 →
服务端用
openid+ 验证码绑定设备并签发 session。未认证订阅号即可跑， 但服务端与 MFC 端都要改，UX 多一步。
Why: 主体类型与接口权限是「从代码里看不出来」的外部约束，直接决定架构能否上线； 照着现有代码改一堆，最后会卡在这个接口权限上。
How to apply: 讨论「切正式号 / 上线」时先看本文件。不要再建议「用订阅号试试」， 除非确定走路线 B。微信测试号（拥有全部接口）只能作过渡，不能上生产。