授权页面还没打开，就出现10003

用户从公众号菜单或聊天消息进入网页，页面尚未显示业务内容，微信便提示“redirect_uri域名与后台配置不一致，错误码：10003”。这类报错通常发生在公众号网页授权环节：授权链接中的 redirect_uri 是微信完成授权后要返回的地址，微信会将它与该公众号配置的网页授权域名核对。

此时，先从用户实际打开的链接入手。页面最初的入口地址、授权链接里的回调地址，可能不是同一个域名。开发环境能用、正式环境报错，也可能是正式链接生成时带上了另一个主机名。仅查看浏览器最后停留的报错页，容易漏掉此前的跳转。

链接里是m域名，后台填的是www域名

假设一个公众号的后台配置了 www.example.com，业务网页则通过 m.example.com 提供移动端服务。运营人员点击公众号菜单后遇到10003，开发人员查看实际发出的网页授权链接，发现 redirect_uri 指向 https://m.example.com/wechat/callback。两个地址看起来属于同一网站，但这里需要核对的是回调地址所用的域名，不能因为它们都属于 example.com 就按相同配置处理。

处理方向取决于回调接口放在哪里。如果回调本来就由移动端域名承接，便按公众号平台当前要求配置对应的网页授权域名，并完成平台要求的验证；如果回调接口实际部署在 www.example.com，则检查生成授权链接的代码，把 redirect_uri 改回真实可访问的回调地址。不要只为消除报错而随意替换域名：微信返回后，该地址仍要能接收授权结果，并把用户带回原来的业务页面。

修改后，运营人员重新从公众号菜单进入，开发人员同时查看新生成的授权链接。这次10003是否消失，只能说明域名核对走到了下一步；若随后出现回调接口报错，还得继续检查接口本身，不能把两类问题混在一起。

后台已经改了，报错却还在

核对后台时，找的是网页授权域名，不要把JS接口安全域名或业务域名当成同一项。还要确认当前授权链接中的 appid 对应的就是正在修改的公众号。团队管理多个公众号时，改对了域名却改在另一个账号下，实际发出的链接仍会报错。

另一个容易漏掉的位置是链接生成过程。redirect_uri 往往经过URL编码，直接扫一眼整条链接不容易认出域名。将它解码后，查看完整回调地址；同时检查菜单配置、页面跳转代码中是否还留着旧域名。若链接先经过中间页面，也要记录最终发往微信授权接口的地址，而不是只核对用户最初点击的入口。

后台配置提交后，保留一条重新生成的授权链接进行测试。继续报10003时，把该链接解码后的回调域名、实际 appid 与后台已保存的网页授权域名放在一起核对；若错误已消失而业务页面仍无法打开，就转向检查回调接口和后续跳转。