先看结论：图片显示正常，还要验证实际扫码
实际处理日期：2026年10月2日。群合官网新增微信与WhatsApp联系码时，媒体处理过程曾自动把PNG转为WebP。最终恢复原PNG及正确的媒体信息，并检查源文件、公开图片和页面实际显示的二维码。
原件与截取文件的解码结果一致；桌面1440px、手机390px和320px中实际显示的6张二维码均识别成功。扫码目标正确，不等于已经添加好友或发送消息。
问题在哪里：上传的文件与线上显示的文件可能不同
联系码来自本人原始二维码。制作时仅截取二维码及白色静区，没有使用AI重绘，也没有改变跳转目标。但媒体生成过程发生格式转换，导致需要重新确认公开地址、文件格式和媒体元数据是否对应。
二维码小、图案密集，页面缩放、裁切、压缩和缓存都可能影响识别。只检查后台预览或一张大图，不能证明客户在手机上看到的版本可以扫码。
怎样处理：先保留原码，再修复媒体与显示
- 原始二维码独立保存，仅截取码区及白色静区，不重绘二维码图案。
- 恢复公开PNG与正确的附件元数据，避免继续套用发生自动格式转换的处理流程。
- 页面图片保持原比例，预留白色边缘；二维码与对应联系入口一起显示。
- 清理相关缓存后重新读取公开图片及页面，并保留修复前备份和恢复方式。
怎样验证：三个层面分别核对
- 原件：原件和截取文件共4次解码，结果一致。
- 公开文件：两张PNG返回HTTP200，SHA-256与生产源稿一致。
- 真实显示：从桌面1440px、手机390px和320px的实际页面截取6张码，分别解码核对目标。
- 页面入口：当次检查覆盖211个公开地址，页眉电话、微信同号说明、页脚双二维码均能正常显示并完成检查。
文首配图为群合官网实际联系区截图，2026年10月5日截取，用于展示当前联系区的布局；211个地址是10月2日的检查范围；网站内容持续更新，地址数量可能变化。
类似二维码问题，可以先检查什么？
先检查是否用了真实原码，再确认图片有没有被裁切、拉伸或换成其他格式。随后检查公开文件是否与原件对应，最后在实际手机与桌面显示尺寸中扫描。二维码目标、页面呈现和消息发送是不同状态，应分别验证。
电话和二维码需要在每个页面容易找到，也应避免固定按钮遮挡正文或表单。联系方式属于全站共享内容，统一维护比逐页复制更容易保持一致。
此记录没有进行拨号、添加好友或测试消息发送；没有公开私人聊天、后台凭据或签名下载链接。
遇到同类问题？提供网址、完整错误提示及发生时间，便于判断排查范围。约定的后台处理由群合执行。
