公众号网页授权提示 redirect_uri 域名与后台配置不一致时，不要只反复改域名。授权 URL 中的 AppID 决定了应对照哪个公众号配置；旧项目的一次问题正是复制配置后忘记更换 AppID。

看实际发出的授权 URL

2018 年记录中，域名看起来已经设置正确，但调用仍报 10003。后来发现请求沿用了另一公众号的 AppID，改为当前应用后恢复。

排查应从浏览器实际跳转地址开始，逐项对照：

内容要核对的对象
appid当前业务使用的公众号
redirect_uri解码后真正要返回的完整地址
scope这次申请的授权范围
后台授权配置与上述 AppID 对应的账号
运行配置当前 profile、部署环境和最终拼接值

只看配置文件中的一行域名，不能证明运行中使用的也是这一行。

回调地址不要漏编码或重复编码

构造 authorize 地址时，redirect_uri 是一个参数值，应对这一个值进行恰当编码。检查时先解码看回调目标，再确认编码层次，而不是把整个 URL 多次 urlencode。

回调目标通常应由服务端配置或允许列表确定，不能直接接收任意用户 URL 作为跳转地址。state 也应绑定当前授权会话并验证，不能把固定字符串当作完整的防重放设计。网页授权文档入口

同一个错误码未必指向同一个原因

另一篇旧记录中，开发者工具报类似错误，手机和工具表现不一致，后来还检查了开发者身份相关设置。它说明调试入口也需要纳入对照，不足以证明 10003 永远由域名或开发者身份造成。

应记录具体错误文本、请求参数、使用的 AppID 和调试入口，避免只按错误码搜索并盲目套用处理方法。日志中不保存 AppSecret、授权 code 或完整用户身份数据。

授权是否展示确认页，则是另一层问题，见授权范围与静默跳转。域名检查通过不等于全部身份流程已经完成。