大佬们早上好！
公司是做小程序的，需要连接后端服务器请求数据。
当前公司有一套测试环境服务器和生产环境服务器。测试环境通过 IP 访问，生产环境通过 IP 或者域名访问。
但是有时候会发生上线前检查不仔细，测试环境的 IP 被带到了生产环境，导致生产环境的小程序不可用。
我想过一个方案，就是测试环境和生产环境都使用域名进行访问后端服务，在测试环境使用修改 hosts 的方式来修改域名对应的 IP ，但是放在小程序上这招不行。
除了上线之前加强检查，生成体验版本进行尝试以外，从技术的角度，有办法解决吗？
谢谢

小程序开发工具那里，页面参数之类的传个值，规定开发环境。默认不填就是生产环境。那不就好了。部署不用做任何修改。

这就相当于环境变量，你再去总 API 配置那里，写好业务逻辑，搞定。

js const accountInfo = wx.getAccountInfoSync(); this.globalData.env = accountInfo.miniProgram.envVersion; let baseUrl = ' api.xxxx.com'; if (this.globalData.env === 'develop') { baseUrl = ' beta-api.xxxx.com'; }我是这样的处理的。

这个是软件工程的典型错误，既不应该在进入测试阶段后仍然修改代码。无论是任何理由。所以：1 、通过 url 的特殊调试参数。2 、通过反向代理服务的方式调整 API 的 IP 指向。一般来讲，成熟的产品都会选择方法 2 ，因为方法 2 不光会实现此功能，也是灰度更新、热回退等版本管理的基础机制。

我们是一个标准文件,上线发版前手动改为生产环境再提交,git 上都是测试环境

你可能需要的是 wx.getAccountInfoSync()

秘籍开关，切换环境

1.config 配置文件， 例如：const mode = 'dev' // dev | pro2.脚本上传代码： 例如：npm run dev || npm run build (实际上也是修改配置)3.两个微信小程序，一个是测试环境 一个是正式环境

最简单写个参数呗..还不行 就切域名呗

这个方法很适合，看来还是得先去搜下文档，这个问题明明官方文档就能解决我却没去搜，实在是不应该。谢谢大佬们！

管理问题不应该考虑技术解决

考虑使用网关，可以在网关控制台进行切换，也可以做灰度发布

1. 自己在内网搭 dnsmasq 跳测试服务 ip2. 在登陆时为测试账号授权并推送服务切换3. 记得做独特的标记展示来让测试时可以确定当前是哪个服务

小程序里始终有多套环境参数，在构建的时候指定环境变量来决定走哪套环境。

改 DNS 就完事了

正解，小程序有自己的变量区别环境也可以把域名放进配置里做自动化部署const accountInfo = uni.getAccountInfoSync()const envVersion = accountInfo.miniProgram.envVersionimport siteConfig from '@/utils/config.js'let baseUrl = ''if (envVersion === 'develop') { baseUrl = siteConfig.devBaseUrl} else { baseUrl = siteConfig.prodBaseUrl}

谢谢大佬。我也存在这个问题。之前百度搜都没结果。之前都是手动修改 baseUrl 的。谢谢大佬

如果有 build 这个过程可以参考一下这个，使用环境变量： "test": "cross-env BUILD_ENV=test node ./ci/prebuild.js && cross-env NODE_ENV=development UNI_PLATFORM=mp-weixin vue-cli-service --mode test uni-build --watch" "build-test": "cross-env BUILD_ENV=test node ./ci/prebuild.js && cross-env NODE_ENV=production UNI_PLATFORM=mp-weixin vue-cli-service --mode test uni-build --minimize && cross-env ROBOT=2 node ./ci/autoUpload.js"

＃10 其实可以参考安卓进开发者模式的逻辑，在关于或者 logo 之类的留个长按 3-5 次之类的可以调出开发配置之类的，默认写的都是生产环境，测试就让测试人员手动调整到测试环境去，还有什么日志等级、调试工具条什么的也可以放里边，而且吧其实这个到正式版其实也是有用的，比如某些不太方便在生产环境复现的逻辑也许正式版上切换调试 bug 流程的也很方便

根本问题其实不就是把会变的地址写死在了代码中了么，你们可能每变一次环境还要手工改一下再提交吧。可以查查环境变量是怎么用的，dotenv 是怎么用的。一般用了框架了的话都有成熟的解决方案。完全原生，也要想想怎么写个构建脚本。最后把 CI/CD 用起来。