网站在开发人员电脑上能打开，不等于客户能完成询盘。同一个页面，从手机聊天窗口进入、切换到附件选择器再返回，可能出现与桌面不同的结果。兼容性验收真正要回答的是：约定客户环境里，关键任务能否完成，失败后能否理解并继续，而不是所有设备上的像素是否完全相同。
企业无需先学会各种浏览器技术。只要把访问环境、业务任务和完成证据写清楚，就能把“我这里正常”的争论变成可以复现、可以判断的验收。
范围写到设备、入口和版本，不只写“支持手机”
先列客户从哪里进入：搜索结果、邮件链接、广告落地页，还是聊天工具中的链接。再结合实际访问数据和目标客户确定优先环境。桌面浏览器与应用内置浏览器应分别记录；同一手机上的两个入口，也不能自动视为测试过同一环境。
每个环境注明设备、操作系统、浏览器或宿主应用版本，以及检查日期。没有历史数据的新站，可按目标市场和预计推广渠道确定一份临时范围，标明依据，等获得真实反馈后再调整；不要把猜测写成“覆盖全部客户”。旧版本的支持边界也应事先约定。
桌面窗口缩成手机宽度，能帮助检查排版，却不能完整替代真机上的软键盘、文件选择、权限和应用切换。工具模拟适合快速发现问题，关键移动流程仍需在约定的实际环境中完成。
把环境放在行里，把客户任务放在列里
以下是虚构工业产品网站的验收设计，不代表某种浏览器已通过测试。实际表格应填写具体版本与证据，不能只在整行打一个勾。
| 约定环境 | 查找并阅读产品 | 取得规格资料 | 提交带附件的询盘 |
|---|---|---|---|
| 客户常用桌面环境 A | 筛选型号，打开详情，核对参数 | 下载后打开，核对产品与版本 | 选择附件，提交并核对接收记录 |
| 目标手机浏览器 B | 导航可用，参数不被遮挡 | 能打开或取得文件，有返回路径 | 键盘不挡住错误提示，返回后能继续 |
| 主要聊天应用内入口 C | 分享链接打开正确产品 | 不支持时有明确可行的替代路径 | 上传失败不冒充成功，保留可恢复信息 |
下载按钮有反应，不等于客户拿到了正确文件；询盘按钮变灰，不等于需求被接收。每个格子都写到业务终点：产品是哪一款、资料是哪一版、询盘记录中是否有正确字段和附件。动画、截图可以辅助说明，不能代替这些结果。
分清必须修复、需要认可的替代和可接受差异
核心任务被阻断，应列为必须解决的问题：导航打不开、提交被遮挡、实际未保存却显示成功、附件关联到错误询盘，都不能靠备注“兼容性差异”放行。涉及资料错误时，即使只发生在少量环境，也应按实际影响处理。
字体换行、阴影或过渡动画略有不同，如果内容完整、层级清楚、操作可用，可以约定为显示差异。MDN 的跨浏览器测试资料同样强调，核心功能可用不要求所有环境提供完全相同的视觉体验。但“可以不同”不是放任按钮挤出屏幕、文字被截断或提示看不见。
某个入口确实无法使用增强能力时，替代路径需要单独验证。例如应用内不能完成某种文件操作，可提示在系统浏览器继续，并保留正确产品入口；如果切换后需要重新填长表单，或客户不知道如何返回，就仍有明显缺口。替代方案影响哪些客户、增加多少步骤，应由业务方确认，而不是开发人员单方面标记通过。
一条能修复的故障记录，应当长什么样
假设测试中出现以下问题：“在约定手机环境 B，从产品 P100 页面进入询盘，填两段需求，选择允许类型的测试附件后取消，再次选择；页面仍显示旧文件名，提交后接收记录没有附件。”这比“手机上传不好用”更能指向需要复查的操作。
记录应包含页面地址、环境版本、登录与权限状态、操作顺序、预期结果、实际结果，以及对应的脱敏截图或测试记录编号。标清是每次发生还是偶发；附件类型和大小也要留证，但不把客户私密文件直接贴进公开问题单。开发人员首先要在相同条件下复现，再定位差异。
若不能复现，保留为待确认问题，并缩小条件：直接打开与分享进入是否不同，首次访问与缓存后是否不同，允许与拒绝权限是否不同。不要把清缓存后暂时正常直接写成“已永久修复”。
修好一处后，回归原路径和相邻流程
修复附件问题后，先重复同一环境、同一操作顺序，确认文件名、提交内容和接收附件一致；再检查不带附件、正常选一次附件及其他约定环境。这样既证明原故障消失，也能发现修复是否破坏了原本正常的路径。
最终交付应能看出测试日期、网站版本、环境矩阵、关键证据和遗留问题。未测试、测试失败、以替代方式通过要分开标注。后续更换播放器、客服插件或表单组件时，针对受影响任务重测；一次验收说明当时约定范围内已验证，不代表以后所有浏览器更新都自动兼容。
需要制定建站或改版的兼容验收范围，可以私聊客服，提供客户常用入口和必须完成的业务任务，沟通测试环境、替代路径与交付证据。
参考资料：MDN：跨浏览器测试入门。
