最稳妥的本地短信开发方案是使用 Mock 服务拦截真实请求：可用 json-server、msw 或 Express 中间件模拟响应；SDK 可自定义 endpoint 或 HTTP 客户端；Docker 可快速启动 fake-sms-gateway；回调测试需用 ngrok 等隧道工具暴露本地服务。
用 Mock 服务拦截真实短信请求
本地开发时调用真实短信接口不仅浪费配额，还可能触发风控或被运营商拦截。最稳妥的方式是让代码“以为”在发短信，实际不发出任何网络请求。
推荐用 mock-server（如 json-server 或 msw）在本地起一个 HTTP 服务，把所有发短信的 POST 请求（比如 /api/v1/send-sms）全部响应为 { "code": 0, "msg": "success", "data": { "sid": "SM123456789" } }。
- 如果后端用 Node.js，可直接在 Express 中加一层中间件，匹配
POST /sms并res.json()返回模拟结果 - 前端若走 CORS，记得在 mock 服务中设置
Access-Control-Allow-Origin: * - 别忘了在环境变量里区分
NODE_ENV=development，只在本地启用 mock
替换 SDK 的底层 HTTP 客户端
多数短信 SDK（如阿里云 @alicloud/pop-core、腾讯云 tencentcloud-sdk-nodejs）都支持传入自定义 httpRequest 或 requestOptions。这是比全局拦截更干净的做法。
以阿里云为例，初始化 client 时可以这样绕过真实请求：
const Core = require('@alicloud/pop-core').default;
const client = new Core({
accessKeyId: 'xxx',
accessKeySecret: 'xxx',
endpoint: 'https://smsmock.local', // 指向本地 mock 地址
apiVersion: '2016-09-27'
});
- 关键不是改
endpoint，而是确保这个地址能被你的 mock 服务监听并响应标准 JSON - 部分 SDK（如旧版腾讯云）会校验
Host头或签名中的域名，这时需用localhost+ 修改/etc/hosts映射到真实域名（例如127.0.0.1 sms.tencentcloudapi.com） - 注意签名逻辑是否依赖时间戳或随机数——mock 响应里要保持字段结构一致，否则上层解析会报错
用 Docker 快速启动带日志的 Fake 短信网关
不想写 mock 逻辑？用现成的轻量 fake 服务更省事。比如 fake-sms-gateway 这类镜像，启动后自动监听 :8080，所有请求都打印到控制台并返回成功。
执行这条命令就能跑起来：
docker run -p 8080:8080 --rm -it ghcr.io/robertkrimen/fake-sms-gateway
- 它默认响应
200 OK，且把请求 body、headers 全部输出到终端，方便你确认参数是否拼对 - 如果你的短信 SDK 强制要求 HTTPS，就别用这个——它只提供 HTTP；此时应回退到自建 Express mock +
mkcert生成本地证书 - 别把
fake-sms-gateway镜像放进生产 CI 流程，它没做任何输入校验，恶意构造的 payload 可能导致日志爆炸
验证回调地址是否可达（针对接收回执场景）
有些业务需要接收运营商的上行短信或状态报告，这时你得有个公网可访问的地址供第三方 POST 回调。本地无法直接暴露 80/443，必须借助隧道工具。
推荐用 ngrok http 3000（假设你的回调服务跑在 localhost:3000/callback/sms），它会分配一个类似 https://a1b2c3d4.ngrok.io 的临时域名。
- 把该域名填进短信平台后台的「上行回调 URL」或「发送回执 URL」配置项中
- 确保你的本地服务对
POST /callback/sms路由有处理逻辑，并打印原始 body（运营商回调格式五花八门，比如阿里云用表单编码，腾讯云用 JSON） - ngrok 免费版有连接时长和带宽限制，如果测试频繁中断，就换
localtunnel或自己搭 frp
