debug 初体验2026-03-30

给网站加上留言之后，我关心的其实是两件事：访客能不能顺畅地完成「想说一句话」，以及 页面上呈现的信息是否可信、且没有明显 bug。最开始，留言区域在首屏和后续交互里表现不一致，这时候我先把问题描述成「用户第一眼看到的东西，和真正用起来是否自洽」，而不是急着钻到实现里。最后的选择是：让表单在访客真实使用的那一侧完整出现，避免「首屏一套、点进去又一套」的割裂感。

另一条线是时间：如果评论旁边赫然写着 Invalid Date，对访客来说等于「这条信息不可信」。我的判断很简单：明显错误的内容，不应该原样摆在用户面前。 先搞清楚第三方服务到底返回了什么，再决定展示什么：能显示人类可读的时间就显示，对不上就宁可留白，也不拿一串错误字符串糊弄过去。

还有几次是「体验成本」的问题：发帖成功后，上面的留言列表会整段闪一下，但新留言本来就要审核，列表里本来也不会立刻多一条——那次刷新几乎没有带来信息增量，只是在消耗注意力，于是拿掉。表单里去掉邮箱，也是减少「要填什么」的犹豫。项目列表上给每条想法加评论数，是为了让我一眼看到哪些地方真的在产生对话，更像在做反馈闭环，而不是只看静态介绍。

在多次改动后遇到了一种场景；我这边已经改好了，怎么线上还是旧的？ 后来才理清：有时是改完没 commit、没 push，远端自然还是上一版；有时是线上已经跟着部署变了，本地预览却像没动，要先确认是不是同一套仓库、同一分支，再用稳定的开发命令起预览，必要时清一次本地构建缓存。还有几次是端口被占用，终端自动换到 3001、3002，浏览器还盯着旧的 localhost，误以为没更新。再后来我会把 本机预览 和 正式站点 当成两条环境——没走到发布，访客看到的就不是你手里的那一版；本地和线上对不上时，我先对齐「代码有没有同步、预览是不是这一个进程、地址有没有看错」，再怀疑是不是改错了。

所以这段 debug 对我来说，更像产品经理日常的那套：先把问题说清楚（影响谁、表现是什么、期望是什么），再决定先动展示、先动数据，还是先动发布链路。 少做「试一下行不行」的盲动，多做一点「这一步到底解决的是哪一类问题」的自问——算是我自己的一点入门心得。