Bug复现描述须明确环境、操作、异常三要素：先写OS+浏览器/客户端具体小版本及测试域名，再用→串联可重复原子操作，最后提供截图/控制台错误/网络响应等可观测证据。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
写Bug复现描述时，必须让开发一眼看出“在哪台机器、用什么操作、触发了什么异常”，缺一不可。环境不写清，开发可能在Windows上试Mac的Bug；步骤漏一步，复现率直接掉到0%；结果没截图或日志，等于只说“它坏了”却不告诉怎么坏的。
第一步：固定环境信息，按优先级排序写
先写操作系统+浏览器/客户端版本，再写后端服务版本（如有），最后写测试账号权限级别。顺序不能乱——前端问题看OS+浏览器，后端接口问题看服务版本，权限类Bug必须标清账号角色。
这一步操作起来很简单，直接复制系统设置里的版本号就行。但【务必写具体小版本号，比如Chrome 124.0.6363.91，不能只写Chrome 124】。写成“Chrome最新版”会让开发卡在版本差异上白耗两小时。
如果用的是内部测试环境，必须注明域名或IP，例如 test-api-v3.internal.company.com，不能只写“测试环境”。
第二步：拆解操作路径，用→串联关键动作
从登录开始，每一步都是可逆、可重复的原子动作。跳过“打开网页”这种默认动作，聚焦真正触发Bug的交互点。
方法一：标准线性路径（推荐用于单路径Bug）
登录→进入「订单管理」页→点击右上角「导出Excel」按钮→在弹窗中勾选「含退款明细」→点击「确认导出」→等待3秒后页面卡死，无任何提示。
方法二：分支路径（适用于条件触发Bug）
登录→进入「用户编辑页」→修改手机号为已存在的号码→点击保存→观察提示框文字是否显示「手机号已被注册」→此时点击取消按钮→再点一次保存→提示框变成空白。
注意：不要写“尝试多种方式”，要写“第几次点击、哪个按钮、输入什么值”。开发不是猜谜游戏。
第三步：结果描述必须包含可观测证据
只说“功能失效”是无效描述。必须提供至少一种可验证的输出：
方法一：界面表现（截图最直观）
页面顶部出现红色Toast提示「Internal Server Error」，持续5秒后自动消失，但列表数据未刷新。
方法二：控制台错误（前端Bug必备）
F12打开Console，捕获到Uncaught TypeError: Cannot read property 'length' of undefined，堆栈指向utils.js第47行。
方法三：网络请求异常（接口类Bug核心）
Network标签下，/api/v2/orders/export 请求返回500状态码，Response Body为{"code":500,"msg":"null pointer exception in OrderExportService"}。
【严禁写“和预期不符”这种模糊表述，必须写清楚“预期是什么、实际看到什么”】
第四步：附加信息决定复现效率上限
第一步：检查是否偶发
该问题在连续5次操作中稳定复现，非偶发。同一账号在另一台Mac设备上同样复现，排除本地缓存干扰。
第二步：提供对比基线
相同操作在生产环境v2.8.1版本中正常导出，仅在测试环境v2.9.0-rc2中出现此问题。
第三步：附最小复现数据
已将复现所需数据简化为单条订单：订单号ORD-TEST-7782，用户ID为test_user_001，可在测试库中直接查到。
