订单列表页“一键催发货”按钮需满足orderStatus==='wait_ship'且canUrgent===true才渲染，点击后通过防抖+loading状态防止重复提交，并同步更新本地urgentCount与UI文案，成功后展示“已催促（x次）”及客服响应提示。
订单列表页怎么触发“一键催发货”按钮
按钮本身只是个 v-if 控制的 DOM 元素，关键在它出现的条件和点击后的逻辑。不能只判断订单状态为“待发货”，还得排除已过催单限制（比如 24 小时内最多催 1 次）、当前用户是否为下单人、订单是否已被商家标记“已处理”。
常见错误现象：催发货 按钮在“已发货”订单里还显示；点击后没反馈，也没调接口；安卓真机上按钮点击区域失效（没加 cursor: pointer 或 touch-action）。
- 只对
orderStatus === 'wait_ship'且canUrgent === true的订单渲染按钮 - 后端需返回
lastUrgentTime字段，前端用Date.now() - lastUrgentTime > 24 * 60 * 60 * 1000判断是否可再次催 - 按钮绑定
@click="handleUrgent(item.id)"，别用@tap（iOS 下可能延迟） - 加
user-select: none防止长按唤出菜单干扰操作
催发货请求怎么发才不被重复提交
用户手抖连点两次，“催发货”变成“催了两次”，后端收到两条相同请求，客服看到重复工单——这不是体验问题，是逻辑漏洞。uni-app 里没有内置防抖机制，得自己控。
不能只靠 loading 状态禁用按钮，因为网络慢时按钮恢复太快，用户仍可能再点；也不能全靠后端幂等，前端必须先拦住。
- 点击后立即设
item.urgentLoading = true，按钮v-bind:disabled="item.urgentLoading" - 请求成功后，手动重置
item.urgentLoading = false，别依赖响应自动恢复（失败时也要恢复） - 接口返回成功后，建议同步更新本地订单状态字段，比如
item.urgentCount += 1，避免刷新前状态错乱 - 别用
setTimeout模拟节流——真实网络耗时不可控，应以请求完成为唯一信号
催发货后 UI 怎么反馈才不突兀
弹个 uni.showToast 就完事？用户根本不知道催单是否生效、客服有没有看到、下次还能不能催。真正的反馈要闭环。
淘宝的做法是：按钮变灰 + 文字从“催发货”变成“已催促（1次）”，同时订单卡片顶部加一个淡黄色小横幅：“客服已收到催单，通常 2 小时内响应”。这个信息比“操作成功”有用得多。
- 成功后改按钮文案为
已催促（${item.urgentCount}次），并禁用 - 用
uni.showToast({icon: 'success', title: '已提醒商家' })，别用none图标 - 如果后端返回了预计响应时间（如
expectReplyAt: "2小时后"），直接展示在订单卡片上，比通用提示更可信 - 别在列表页顶部统一弹 Toast —— 用户可能正在滚动，弹窗会遮挡当前订单项
为什么真机测试时催发货总失败
开发工具里一切正常，打包成 App 后点击无反应，或报错 request:fail errCode:-1，大概率不是接口地址错了，而是权限或域名配置漏了。
尤其注意 Android 打包后，uni.request 默认走 HTTPS，但如果你的催单接口还是 HTTP，就会静默失败；iOS 更严格，连证书链不完整都会拦截。
- 检查
manifest.json中 “网络请求合法域名” 是否包含催单接口的域名（不是主站域名，是单独的 API 域名） - 确保接口地址写的是完整 URL，别用相对路径（
/api/urgent在 H5 可行，App 和小程序不行） - Android 真机若报错
net::ERR_CLEARTEXT_NOT_PERMITTED，说明用了 HTTP 协议，必须切 HTTPS 或在android/app/src/main/res/xml/network_security_config.xml里显式允许 - 微信小程序还要额外配置
request接口域名白名单，且不能带端口
最易忽略的点：催发货是高频低优先级操作，别让它阻塞订单列表的滚动或下拉刷新。所有请求都该设 timeout: 8000，超时后自动恢复按钮状态，而不是一直转圈卡住整个列表。
