用户点击提交后，页面毫无反应，进度条停滞，也没有任何弹窗提示，于是连续点击了好几次，最后留下一句“小程序坏了”。这类情况在小程序开发和维护中并不少见，但界面无响应并不代表提交一定失败了。请求有可能已经送达服务端并成功写入，只是结果没能返回用户眼前；也可能请求压根没有发出。排查时如果一开始就动手改业务代码，常常会越改越乱。更稳妥的方式是沿着用户端到服务端的顺序分层检查，先找到断点，再判断该改哪里。
前端层可以先看三个位置。第一是按钮的防重复点击机制。有些实现会在首次点击后马上禁用按钮，但如果请求结束后禁用状态没有恢复，用户面对的就是一个再也点不动的按钮。第二是请求超时配置。超时时间太短，弱网环境下请求会被提前中断；超时时间太长，用户又长时间得不到任何反馈。建议明确设置超时，并在超时后提供可重试的提示。第三是错误提示是否被遮挡或遗漏。弹窗组件被其他元素盖住、提示文案为空、错误分支只写了日志而没有界面反馈，都会造成“点了没反应”的感受。检查时可以在提交函数里临时加入状态输出，确认代码实际执行到了哪一步。
网络层可以排查四个点。接口域名是否配置正确，测试环境和正式环境是否混用；HTTPS证书是否在有效期内，证书链是否完整，部分安卓机型对证书问题更敏感；小程序后台的服务器域名白名单是否包含当前接口地址；请求体大小是否超出限制，图片或长文本一次性提交时容易被忽略。这一层的问题通常表现为请求发出但被拦截，或者在开发者工具里正常、真机上失败。用真机配合抓包工具交叉验证，比只看控制台更可靠。
服务端层重点看接口日志和限流策略。先确认请求是否到达网关或应用，再看参数是否通过校验。如果接口配置了频率限制，用户连续点击可能触发限流，返回的状态码却没有被前端正确处理。入库失败也要区分是字段约束、唯一索引冲突还是连接超时。涉及异步任务的场景，接口返回成功只代表任务已受理，真正的处理结果需要另查任务状态。把受理和处理分开表达，用户才不会误以为已经完成。
给一份逐层自查清单：用户端确认按钮状态是否恢复、是否有可见提示；前端确认超时设置、错误分支、请求参数；网络确认域名白名单、证书、请求体大小；服务端确认接口日志、限流记录、入库结果、异步任务状态。每一层都留下可查的记录，问题就不会在层与层之间被推来推去。it数运在小程序开发和维护中，习惯把反馈链路拆成受理、处理、结果三段分别确认，让每一次提交都有明确去向。技术有章法，服务有回应，用户点下按钮之后发生什么，应该是清楚的。
