自己留过备用的马蓉出轨事件,入口失效了怎么找回来,真实使用感受 免费观看高清-B站

你先记个画面：客户老板坐在我对面，手机横过来给我看一张截图。截图里是他厂里的网站，在手机上排版全乱了，图片撑出了屏幕，底部电话点不动。他不说话，就看着我。那个眼神我到现在都记得——不是生气，是失望，因为他觉得你专业，结果你给了他一个半成品。

那是四年前的事了。我在恩施帮一家做富硒土豆的厂改站，三十来人的厂，老板姓周，自己跑市场。网站是他花两千块找人做的，后来那人跑路了，他找到我。我当时觉得这种小站改改不难，结果打开后台一看——模板里嵌了四套不同版本的 jQuery，CSS 全是行内样式，数据库连了三次不同的连接串。这他妈怎么做？

第一次崩溃：没有自查表的日子

我那会儿干活全凭脑子记。改完一版，自己觉得没问题了，就扔给客户验收。你别说，小毛病客户自己发现不了，但是大问题——比如韶关那个做马蹄粉的客户，我上线当天晚上他们销售打电话来说注册页点提交没反应，我还在外面吃宵夜。老板第二天直接给我发了个语音，语气倒是客气，但那个 "没事没事，你看一下就行" 我听了三年都记得。

这事儿暴露了一个本质问题：人的注意力是有限的。我改代码的时候脑子在想着逻辑，就顾不上样式；调样式的时候又忘了测表单。而且我这个人还有个毛病——改完总觉得自己没问题，特别自信地就提交了。后来我给自己算过一笔账：没有自查表的半年里，平均每个项目返工 2.3 次，每次返工浪费至少半天。一年算下来，二十来个项目，光返工就吃掉我两周的时间。

具体症状：17 个 bug 同一个成因

我做过的项目里，至少有 17 个问题是因为忘记在 Chrome 开发者工具里切到移动端视图。17 个。这数字我为什么记得？因为我后来做了一张表，专门记自己的踩坑次数，前三个反复犯的错误加起来占了总错误的 68%。你看，连记录这件事本身，也算是一张自查表了。那时候我才意识到，不是我不认真，是我没有一个流程来兜底。

第一张自查表长什么样

讲白了，我的第一张自查表就是从这几个反复犯的错里抽出来的。我花了一个周末把它写成了二十条的清单，打印出来贴在显示器右边。后来客户那边的技术负责人老黄——一个在韶关做工厂网管做了十五年的大叔，看到我拿纸质清单在那打勾，笑了我一句 "你们做互联网的还这么土"。但是三个月后他自己也印了一张贴在机房门上。

这张纸质清单长这样：第一栏是 "功能类"：注册、登录、搜索、提交，每一条后面有一格打勾。第二栏是 "体验类"：移动端首屏完整吗、按钮可点击区域够 44px 吗、滚动时导航是不是固定住了。第三栏是 "安全类"：表单有没有限制输入长度、敏感信息是不是 HTTPS。这东西不花哨，但它救过我一次特别惨的——有次给一个卖恩施玉露茶的品牌站改模板，我改完前端以为自己没问题了，结果查表的时候发现登录页的验证码没显示。如果没这张纸，我就不查了。

反例：光有表没用，你得信它

但是，我跟你说，光有自查表是不够的。你得真的去用它。这事儿我吃过两次亏。一次是在给安康的客户做一个小程序 H5 版本的时候，我觉得表里的条目太烦，就想着 "就几条改动，没必要查"。结果上线之后，安卓端微信浏览器里弹窗的确定按钮被键盘顶到屏幕外面去了。客户那边是直接做农产品批发的，老板自己天天在群里发链接，发现按钮按不到，电话直接打给我。当时我正从广州坐高铁回深圳，站在车厢连接处跟他解释了十分钟，最后改了几行 CSS 重新发版。

另一次更丢人。绍兴有个做黄酒电商的客户，我给他们做了个秒杀页面。我觉得功能没问题，没查表就交付了。结果活动当天，页面在 iPad 上布局崩了，因为我在 CSS 里用了 position: fixed 没加 transform: translateZ(0)，Safari 自己就疯了。那场活动原定转化 200 单，最后只走了 37 单。虽然不能说全是布局的锅，但那 37 单里至少有七八个下单用户是在手机上操作的，页面崩不崩他们可能没感觉，但 iPad 用户是真崩了。

正例：自查表帮我省了什么

后来我彻底老实了。每个项目做完，哪怕只是改一个字，也要走一遍自查表。流程变成这样：开发完 → 自己在本地跑自查表 → 把查出来的问题改掉 → 再跑一遍 → 自查通过 → 交测试环境。测试那边再跑一遍他们的表。两套表互相兜底。结果是：返工率从 2.3 次降到了 0.4 次；客户那边验收后提 bug 的平均数从 8.2 条降到了 1.1 条。你也别觉得 1.1 条还是多，那里面一半以上是文案的修改，比如 "这个按钮叫 '立即购买' 还是 '去支付'"，那属于产品层面的事，不是 bug。

而且我发现了一个更微妙的好处：自查表让我在面对客户的时候敢说 "没问题了"。以前我说这话的时候心里是虚的，客户多追问两句我就开始含糊其辞。现在我说 "已经跑过自查表了"，底气就不一样。客户也许不懂技术，但他们能感觉到你说话有没有底。周老板后来在微信里跟我说过一句让我记到现在的话："你比上一个靠谱。" 就这么一句话，值了。

恩施第二回：同样的坑，不同的工具

去年我又接了恩施另一个客户的单子，是做富硒大米的小程序电商。有了之前的经验，我这次把自查表直接嵌到了项目的 GitHub Issue 模板里。每次提交 MR 的时候，自动合并一个 Markdown 格式的 checklist，开发者必须逐项勾完才能点提交。这一步看起来多余，但它硬生生地把我在韶关那个项目里犯的 "未测移动端" 错误率从 17 次降到了 2 次。那两次还是因为换了台测试机，浏览器的旧版本兼容问题没覆盖到。

自查表不是万能的，但它能兜住 70%

我这边的经验是：一张好的自查表能拦下 70% 的线上问题。剩下的 30% 是场景覆盖不到的，比如极端网络环境、用户乱输入长字符串导致服务器超时、第三方接口突然改协议。这些靠自查表挡不住，需要靠架构设计和监控告警来解决。但如果你想先把最基本的底线守住了——页面上别崩、按钮能点、价格别写错、图片别裂——那么一张纸就够了。

而且你也不要觉得做自查表是多高深的事。它就是个穷办法。但穷办法管用。我自己现在做了四个版本的自查表：第一个是通用版，适用于所有项目；第二个是电商版，加了价格、库存、优惠券的校验；第三个是 B 端版，专门针对后台系统，重点查权限和批量操作；第四个是移动端版，专注手势、键盘遮挡、横屏适配。每个版本都不超过三十条，多了你根本不愿意看。

写到最后我想跟你说的是：自查表不是对客户负责，是对你自己的时间负责。你一张表省下来的返工时间，够你再接一个项目。而且客户那边对你建立起信任之后，他们愿意把其他活也给你干。那个做马蹄粉的韶关客户，现在每年找我做两次小程序更新，而且从来不催我。不是因为我技术多好，是因为我给他的东西从来没出过需要他半夜爬起来找我的问题。就这么简单。