共 21 篇
上周帮朋友收尾一个小程序，功能都写完了，提审前我让他先跑一遍测试。他回了一句：本地都点过了，没问题。结果上线第二天，客服群里炸了——iOS 上支付回调没反应，安卓低端机进详情页白屏。这两个问题，本地开发者工具里一个都复现不出来。这篇就聊聊小程序开发测试这件事。不是教科书式的清单，是我自己反复踩坑之后，觉得真正值得花时间的地方。开发者工具只是起点，不是终点很多人把微信开发者工具的模拟器当成测试环境，
很多朋友找我聊小程序，第一句话都是「做个多少钱」。我一般会先问一句：你是只算开发这一锤子，还是算它活着的这几年？前者好回答，后者才是真正让人头疼的地方。我自己手上维护着几个上线两三年的小程序，踩过的坑不少，今天就把运维这块的账摊开说说。开发费是一次性的，运维费是月月见的刚入行那会儿我也天真，觉得代码交付、审核通过、上线，项目就结束了。后来才发现，上线只是开始。小程序不像一个静态页面，它背后有服务器
上周帮朋友收拾一个烂摊子：一个上线两周的小程序，iOS 上好好的，安卓上一进商品详情页就白屏。查了半天，是某个机型上 position: sticky 配合自定义导航栏出了问题。这类事我见得太多，今天就把小程序兼容性测试这块的经验捋一捋，都是踩过的坑。 为什么小程序兼容性比 H5 更麻烦 很多人觉得小程序跑在微信里，环境统一，应该比 H5 省心。理论上没错，但实际情况是： 基础库版本分散。用户手机
组件开发这件事，我踩过的坑比写过的组件还多。刚做小程序那会儿，看到什么都想封装：按钮封装一个、卡片封装一个、连个带图标的文本行都要抽出来。结果项目做到一半，组件目录比业务代码还厚，改一个样式要翻五个文件。后来才想明白，组件不是越多越好，是该封的时候封，不该封的时候忍住。 什么时候才值得抽组件 我的判断标准很简单，满足下面任意一条才动手： 同一段结构在三个以上页面出现，且以后大概率还会加 这块 UI
做小程序这几年，我踩过最大的坑不是某个 API 用错了，而是项目一开始架构没想清楚，做到一半发现页面之间数据乱飞、改一个功能牵动五个地方。后来我把架构这件事前置，返工率明显下来了。这篇就聊聊我自己在用的那套结构，不追求高大上，只求能扛住需求变化。先想清楚：小程序和普通 Web 差在哪很多人拿写网页的习惯直接套小程序，结果处处别扭。核心差异有三点：逻辑层和视图层是分开的，setData 是唯一的通信
做小程序这几年，最怕听到的一句话就是「这次改动不大，顺手就上了」。版本迭代听起来是个常规动作，但真做过的人都知道，一次没准备好的更新，能把一个跑得好好的小程序直接搞进用户投诉群。我手上有个工具类小程序，日活不高，但用户黏性不错。去年有一次改版，只是调了几个接口、换了个首页布局，结果上线当天下午就收到十几条反馈：列表加载不出来、分享卡片打不开。查下来是旧版本缓存的字段结构和新接口对不上，老用户没更新
上线三个月的小程序，用户反馈「偶尔白屏」「支付后没反应」，你打开开发者工具复现十次都正常。这种时候，能救命的只有日志。但很多独立开发者的小程序，日志基本等于没有——要么只在 catch 里 console.log 一句，要么全量上报把后端存储撑爆。这篇聊聊我这两年在小程序日志上踩过的坑和最后沉淀下来的做法。先想清楚：日志不是给开发看的刚做小程序那会儿，我把日志当调试输出用，想打什么打什么。后来发现
上周有个朋友半夜给我打电话，说他的小程序挂了两个小时，直到有用户在小红书上发帖吐槽，他才知道。我问他有没有做监控报警，他说：「云开发后台不是有日志吗？」有日志和能报警，是两码事。日志是事后验尸，报警是提前止血。这篇就聊聊小程序监控报警这件事，怎么用尽量低的成本，把「用户先发现」变成「我先发现」。先搞清楚要监控什么很多人一上来就想接 Sentry、接各种 APM，其实对大多数小程序来说，先把下面这几
很多朋友以为小程序提交审核通过、点一下发布，这活儿就算干完了。说实话，我前几年也这么想过，直到第一个正式接的项目上线第三天，用户反馈“打不开”，我打开后台一看，云函数调用超时，接口报错堆了一屏。那一晚我才真正明白：上线只是起点，运维才是长跑。这篇文章不聊虚的，就说说我这些年做小程序运维踩过的坑和现在固定用的一套方案，适合个人开发者和小团队直接抄作业。先搞清楚：小程序运维到底在“运”什么跟传统服务器
做了几年小程序外包，交付之后最怕听到的一句话不是“有 bug”，而是“服务器又挂了”。前者改代码就行，后者往往意味着半夜爬起来看日志、重启服务、临时扩容，第二天还得给客户写事故说明。这篇文章不讲大道理，就聊聊我这两年在小程序服务器运维上踩过的坑和最后沉淀下来的做法，主要面向和我一样两三台机器、预算有限的小团队。 先想清楚：你的小程序真的需要“服务器”吗 很多项目一开始就上云服务器、装 Nginx、
微信扫码，直接沟通需求
微信扫码，直接沟通需求