问题现象与适用场景
有些场景里，钉钉侧的“测试信息”可以正常发出去，但一旦切换到正式的员工消息发送流程，后台就返回 400。这类问题通常不是“完全连不上接口”，而是请求已经到达服务端，但请求内容不符合接口要求，或者某个必填条件没有满足。
如果你是在阿里云服务器上部署了一个对接钉钉的服务，出现“测试能发、正式发送报 400”的情况，优先不要先怀疑服务器本身坏了，而是先确认：请求体是否一致、鉴权是否正确、消息格式是否符合接口要求、以及后台是否把真实错误信息记录出来。
说明：由于原始帖子信息较少，下面给出的是通用且保守的排查顺序。具体字段名、接口路径和消息格式，请以你当前使用的钉钉接口文档和官方最新说明为准。
常见原因
- 请求参数不完整：正式发送时缺少必填字段，例如接收人、消息类型、内容体、应用标识等。
- 消息格式不符合接口要求：测试消息可能是固定模板，而正式消息拼接后出现了空值、非法字符、JSON 格式错误或字段层级错误。
- 鉴权信息失效或不匹配：access token、签名、应用凭证、回调校验信息等可能在测试流程中被正确使用，但正式流程里没有带上，或者已过期。
- 环境变量或配置项错误：阿里云服务器上的配置文件、环境变量、密钥文件路径、编码方式与本地测试环境不一致。
- 接口地址或请求方法不对：例如测试接口和正式接口不是同一个地址，或者 GET/POST、Content-Type 与接口要求不一致。
- 服务端日志没有把真实错误打出来：前端或调用方只看到 400，但后端实际返回了更具体的错误信息，只是没有被记录。
分步解决方案
1. 先确认 400 是谁返回的
第一步要分清楚：是你自己的后端程序返回了 400，还是钉钉接口返回了 400。两者处理方式完全不同。
- 查看后端日志，确认请求是在哪一层失败的。
- 如果是你自己的接口返回 400，重点检查参数校验、路由、反序列化和表单/JSON 解析。
- 如果是钉钉接口返回 400，重点检查请求体、鉴权和消息格式。
建议把完整响应体打印出来，而不是只看状态码。很多时候真正的错误原因就在响应 JSON 里。
2. 对比“测试信息”和“正式发送”的请求差异
既然测试信息能发，说明基础链路大概率是通的。接下来要做的是把两次请求逐项对比：
- 请求 URL 是否一致
- 请求方法是否一致
Content-Type是否一致- 请求体字段是否一致
- 接收人标识是否一致
- token、签名、时间戳是否一致
如果正式发送时是动态拼接内容，尤其要检查空字符串、中文引号、换行符、特殊符号和未转义字符。很多 400 都是 JSON 格式被破坏导致的。
3. 检查消息体是否符合接口要求
正式消息常见问题是字段看起来“差不多”，但实际上不符合接口规范。可以按下面顺序检查：
- 确认消息类型是否正确，例如文本、卡片、Markdown 等类型不能混用。
- 确认必填字段都已传入，且值不是空。
- 确认字段名拼写正确，没有大小写错误或层级错误。
- 确认内容长度没有超出接口限制。
- 确认 JSON 可以被正常解析。
如果你是用代码拼接 JSON，建议先把最终请求体打印出来，再复制到在线 JSON 校验工具或本地格式化工具中检查结构是否完整。
4. 检查鉴权和权限配置
很多“测试能发、正式报 400”的问题，本质上是权限或凭证问题。重点看：
- access token 是否过期
- 应用凭证是否配置正确
- 是否使用了正确的企业、应用或机器人身份
- 接收人是否在允许范围内
- 是否需要额外的签名或时间戳校验
如果你的服务部署在阿里云免费试用服务器上，还要注意服务器时间是否准确。某些签名校验对时间偏差比较敏感，系统时间不准可能导致请求被判定无效。
5. 检查服务器环境与网络连通性
阿里云服务器本身一般不会直接导致“业务参数正确却返回 400”，但环境问题会间接放大故障。建议检查：
- 系统时间是否同步
- DNS 是否正常解析接口域名
- 是否存在代理、转发或防火墙改写请求
- 程序运行用户是否有权限读取配置文件
- 编码是否统一为 UTF-8
如果本地测试正常、服务器上失败，优先比较本地和服务器上的环境变量、配置文件和运行日志。
6. 用最小请求验证接口
当你怀疑是业务代码问题时，不要直接在完整业务链路里反复试。先构造一个最小可用请求，只保留接口要求的最少字段：
- 最简单的消息内容
- 最少的接收人信息
- 最基础的鉴权参数
如果最小请求能成功，说明问题大概率出在你后续拼接的业务字段上；如果最小请求仍然失败，说明问题更可能在接口地址、鉴权或环境配置。
如何验证是否修复成功
修复后不要只看“页面没报错”，而要做以下验证：
- 确认接口返回状态码不再是 400
- 确认响应体中没有参数校验失败、签名失败或权限不足等提示
- 确认钉钉侧实际收到消息，而不是只在本地日志里显示成功
- 连续发送 2-3 次，确认不是偶发性缓存或 token 过期问题
- 在服务器重启后再次测试，确认配置是持久生效的
如果只是测试消息成功，正式消息仍失败，说明问题还没有真正解决，通常是测试路径和正式路径存在配置差异。
解决不了时的补充建议
如果按上面的顺序排查后仍然报 400，可以继续做这几件事：
- 把后端完整请求日志和响应日志保存下来，重点看响应体里的错误码和错误描述。
- 把正式发送接口的请求体与测试请求体逐字段对比，找出差异。
- 临时关闭复杂拼接逻辑，改成固定文本消息，确认基础链路是否正常。
- 检查是否存在多环境配置混用，例如测试环境 token 被带到生产环境。
- 如果使用的是第三方封装库，先确认库的当前推荐用法是否与接口文档一致，请以官方最新文档为准。
如果你愿意继续定位，最有价值的信息通常是：接口地址、请求体、完整响应内容、后端日志片段，以及“测试信息”和“正式发送”之间的差异。只要把这几项对齐，绝大多数 400 都能定位到具体原因。