共 66 篇
做小程序这些年，被问得最多的问题之一就是：到底该用原生写，还是上框架？这个问题没有标准答案，但有一套可以复用的判断逻辑。这篇文章把我自己在项目里踩过的经验整理成一套选型方法，供你参考。一、先搞清楚框架解决了什么问题微信小程序原生开发用的是 WXML + WXSS + JS/TS 这一套，逻辑清晰、官方支持最全。但它的短板也很明显：只能跑在微信里，想上支付宝、抖音、H5 就得重写一遍；工程化能力弱，
很多人第一次接触小程序开发，最困惑的问题不是“怎么写”，而是“用什么写”。打开微信开发者工具，看到 .wxml、.wxss、.js、.json 四类文件，再听到别人说“小程序可以用 Vue 写”“可以用 uni-app 一套代码发多端”，很容易陷入选择困难。这篇文章从实际项目出发，把小程序开发语言的层次关系讲清楚。 小程序不是一种语言，而是一套技术栈 严格来说，微信小程序没有发明新语言，它是一套以
这篇教程面向已经会一点 JavaScript、但还没有完整做过一个小程序的同学。我们会从环境准备开始，做一个带列表页、详情页和云端数据的小 Demo，把小程序开发中最常用的几个环节串起来。一、准备开发环境开发微信小程序需要三样东西：一个已注册的小程序 AppID（个人主体也能注册，测试阶段也可以先用测试号）微信开发者工具（官方提供，Windows / macOS 都有）Node.js 环境（如果你
每次有人问我「小程序开发到底分几步」，我都想说：步骤本身不复杂，复杂的是每一步里那些没人提前告诉你的细节。这篇不列教科书目录，按我自己接单、自己写代码的顺序，把真实流程和踩过的坑摊开讲。第一步：先想清楚「不做会怎样」很多人一上来就画原型、选框架，我建议先停一下。问自己三个问题：用户为什么不用公众号、H5 或直接打电话，非得打开小程序？核心功能能不能用一句话说清？说不清就说明还没想明白。第一版最少要
做小程序这几年，踩过最疼的坑不是性能，不是审核，而是版本管理。听起来像是个老生常谈的话题，但真到自己一个人维护三四个小程序的时候，才发现这事比想象中麻烦得多。今天不聊大道理，就说说我自己在版本管理上吃过的亏，以及现在跑通的一套流程。一开始我根本没用版本管理刚做小程序那会儿，觉得代码量不大，改完直接点「上传」，填个版本号，提交审核，完事。微信开发者工具自带的版本号，我随手写个 1.0.0、1.0.1
做小程序这几年，被问得最多的问题不是“怎么加功能”，而是“为什么我的小程序用起来有点卡”。说实话，卡顿这东西很玄学，用户不会告诉你具体哪里卡，他只会默默退出。今天就聊聊我踩过的几个坑，都是些不起眼但很要命的细节。首屏加载：别让用户盯着白屏发呆很多人一上来就优化接口，其实首屏最大的问题往往在包体积。微信小程序主包限制 2MB，超了就得分包，但分包不是万能药。我的习惯是：把非首屏的页面、组件、图片全部
经常有人加我微信，第一句话就是：“做个类似美团的微信小程序，两周能上线吗？”每次看到这种问题，我都不知道该怎么回。说不能吧，显得我技术不行；说能吧，那是在骗人。今天就把小程序开发周期这件事掰开揉碎聊一聊，都是这几年踩坑踩出来的经验。 先给个大概的数：不同复杂度对应的时间 不绕弯子，直接上区间。以下时间指的是从需求确认到可提交审核的版本，不含后期运营迭代。 展示型（企业官网、产品介绍、预约表单）：1
做小程序这几年，我越来越觉得调试这件事被低估了。很多人以为写完代码点一下编译，模拟器上跑通了就完事，结果一上真机全是问题。今天就把我踩过的坑和总结出来的调试套路写一写，都是实战里磨出来的。别把模拟器当回事微信开发者工具的模拟器确实方便，但它和真机差距比你想的大。最典型的就是网络环境、设备性能和系统 API 的差异。我遇到过一个很离谱的 bug：模拟器上列表滚动丝滑，真机（某台老安卓）上直接卡成 P
做独立开发这些年，接手过不少别人半途而废的小程序项目，也把自己写的代码交给过别人维护。每次打开一个没有规范的代码库，那种感觉就像走进一间从没收拾过的出租屋——能住，但每找一个东西都得翻半天。今天不聊虚的，就说几个我在真实项目里反复验证过的规范，都是踩坑踩出来的。目录结构别学大厂，够用就行很多教程一上来就给你画一棵三层嵌套的目录树，什么 services、utils、components、pages
做小程序这几年，有个现象一直没变：项目刚开始时，没人愿意写文档；等项目做到一半，所有人都在找文档。尤其是多人协作或者中途换人接手的时候，翻聊天记录找接口参数，比写代码还累。这篇就聊聊小程序开发文档这件事，说说哪些文档真值得写、怎么写才不流于形式。 先想清楚：文档是写给谁看的 很多团队一上来就套模板，需求文档、设计文档、测试文档全套齐活，结果写完没人看。我的经验是，先分清读者： 给未来的自己看：接口
微信扫码，直接沟通需求
微信扫码，直接沟通需求