企业官网建设流程全解析

今天我不打算堆概念，也不想一上来就给你整一套重型架构。我想把 WorkBuddy 这个微信小程序从完全空白，到能提交审核、跑通核心流程的整个过程，完完整整拆开讲。WorkBuddy 不是个大项目，它就是一款给个人和小团队用的轻量待办与工时记录小程序，没有复杂的后台，没有大厂中间件，靠微信小程序原生能力加本地存储就能跑起来。但它足够覆盖你在真实业务里会遇到的大多数问题：注册、工具链、页面结构、数据流转、表单校验、调试上线。这篇文章适合刚接触小程序的人，也适合已经写过几个页面但总在架构和数据管理上犯迷糊的人。

我写的东西不会只给你看“能跑的代码”，我会把每个关键选择背后的原因讲清楚。微信小程序开发不像从前做网页，它有自己的一套生命周期、渲染机制和存储边界。把这些底层逻辑摸透了，你以后再去看别的项目，会发现骨架都是一样的。

1. 项目定位与设计决策

1.1 WorkBuddy 到底解决什么问题

团队协作工具往往做得太重。有人给项目配了全套流程管理系统，结果每天要填十几个字段，最后连点开都嫌麻烦。WorkBuddy 想解决的，是个人在日常工作里最容易丢的那些琐碎事项：一个电话要回、一份文档要交、一次对接要跟进。这些事放进大型看板里显得小题大做，记在本子里又容易忘。

我把 WorkBuddy 设计成三个核心动作：快速记录一条任务，到点提醒自己，完成后简单标记。不做多级分类，不做成员权限，不做循环任务。第一版只回答一个问题——今天还有哪些事没干完。这个克制很关键。很多小程序死掉不是功能太少，而是功能太多，用户进入首页根本不知道该按哪里。你砍到只剩一个核心操作时，用户的学习成本就趋近于零。

从真实使用场景出发，我还加了一个轻量的工时记录能力：每条任务可以附带当天预计投入的时间段。这样到了一天结束，统计页能自动汇总今天完成了几件事，投入了多少时间。它不会替代专业的工时管理工具，但它能让人在不用切换应用的情况下，顺手把一天的工作量留下痕迹。

1.2 原生小程序为什么是第一版的最优解

我见过很多团队一开始就架设跨端框架，用一套代码同时输出微信小程序、支付宝小程序和 App。想法很美好，但为了这份“未来可能多端复用”的预期，你在第一周就要付出惨痛的代价：框架升级要跟进、原生组件要桥接、打包体积会膨胀、调试链路会变长。

做 WorkBuddy 这种轻量工具，原生小程序框架反而更合适。原因有三点：

1. 原生框架的调试体验最稳。微信开发者工具对原生代码的支持最即时，模拟器、真机预览、性能面板都是现成的，出了问题你不需要猜是框架层还是平台层的问题。

2. 没有跨端需求时，任何抽象都是负担。WorkBuddy 的主场景就是微信生态内分享、打开、使用，不需要跑在安卓和 iOS 的独立 App 上。

3. 原生语法的学习成本其实比很多人想象的低。它的页面结构就是 WXML 加 JS 加 WXSS，组件化思路和 Web 开发非常接近，只要你熟悉任何一门前端语言，半天就能上手。

我知道很多人会推荐用 Vue 或者 React 语法去写小程序，理由是效率高、生态好。这个观点我部分认同，但当你面对的是一个可以在两周内完成 MVP 的小工具时，原生方案能让你的代码离微信平台本身的特性和限制更近，踩坑时排查起来更快。等 WorkBuddy 真的需要多端输出时，再迁移到一个成熟跨端框架也不迟，到时核心逻辑抽出来，成本远比你现在猜需求要低。

1.3 页面骨架与数据流规划

开工之前，我用一张纸画页面结构。不需要画多专业，但页面和页面之间的跳转关系必须清晰。WorkBuddy 第一版整体是这样的：

• 任务列表页：默认首页，展示今天的待办事项，支持标记完成和删除。
• 新增任务页：填写任务标题、预计日期、备注，保存后回到列表页。
• 统计页：按日期汇总已完成任务数和累计工时。
• 我的页：占位信息，显示当前版本、本地缓存占用、清空数据入口。

这四个页面里，前端项目里最容易被搞乱的就是数据流。我给自己定了一条规矩：所有任务数据必须经过同一个数据模块读写，页面不允许直接操作存储接口。也就是说，页面调用store.addTask()，而不是自己wx.setStorageSync。这样做的动机很朴素：如果以后从本地存储换成云数据库，我只需要改这一个模块，不用翻遍所有页面去替换调用。

在这个阶段我还没接后端，所以数据流的起点是用户输入，终点是本地缓存，中间经过页面事件处理函数。这个单方向的数据流结构虽然简单，但它强迫你在写每个函数前先想清楚：数据从哪里来，经过什么变化，最终渲染到哪里。

2. 从注册到项目初始化

2.1 注册小程序账号与 AppID

微信小程序不是写完了代码就能跑的，你首先得有一个小程序账号。注册入口在微信公众平台，选“小程序”类型，然后按提示填写邮箱、密码、运营主体。个人主体也可以注册，大多数个人学习项目都用这个，不需要营业执照。

注册过程中你会拿到一个 AppID，也就是小程序的唯一标识，相当于身份证号。开发工具新建项目时会让你填这个 ID，你可以选择“测试号”先试试，但测试号很多权限受限，比如无法真机预览完整功能、无法用云开发，所以我建议直接用自己的 AppID。一个邮箱只能注册一个小程序，别乱填邮箱。

这个环节很多人会卡在“服务类目”选择上。WorkBuddy 属于工具类，你选“工具-效率”就行。类目会影响你后面能用哪些接口，比如涉及到录音、支付、位置之类的接口，需要对应类目才能开权限。WorkBuddy 不涉及这些，所以类目选择很简单。

补充一个经验：注册后不是马上就能开发，一些主体信息需要审核，通常几分钟到半天。建议先把账号注册好、审核通过，再去下载开发工具，两边时间并行，省得干等。

2.2 安装开发者工具并初始化项目

微信开发者工具是官方 IDE，下载稳定版就好。它内置了模拟器、代码编辑器、调试器、真机预览等功能，是成程序的开发和发布入口，在我的实际体验中，官方工具的稳定性和调试面板的信息详细程度都比第三方插件要好用。

新建项目的步骤如下：

1. 打开工具，用微信扫码登录。
2. 选择“小程序项目”，填入项目名称 WorkBuddy。
3. 选择项目的本地目录，注意目录不要放在系统盘，否则文件读写权限容易出幺蛾子。
4. 填 AppID，选择“JavaScript-基础模板”。
5. 点击“新建”，等待工具初始化。

初始化完成后你会看到一整套脚手架。第一次看到这么多文件别慌，真正需要关心的只有几个：

• app.js：全局逻辑，比如小程序启动时要做的初始化。
• app.json：全局配置，页面注册、窗口样式、tabBar 都在这里写。
• index、logs 等初始页面：这是模板自带的示例代码，后面可以删除或改写成自己的页面。
• project.config.json：项目配置文件，记录你的 AppID、编译设置等。

很多人习惯把初始页面直接改造成业务页面，我建议反过来，先删掉示例页面的业务内容，保留空白页结构，然后按自己的目录体系重建。这样你能对项目结构有掌控感，而不是在模板代码上缝缝补补。

2.3 全局配置与 tabBar 搭建

一个正经的小程序总有底部导航栏，这就是 tabBar。它的配置写在 app.json 里。我先规划好自己的四个主页面，然后在 app.json 里注册它们。这里有个新手最容易踩的坑：所有 tabBar 页面必须在 pages 数组里先注册，否则导航栏无法正确显示。

我的 app.json 长这样：

{ "pages": [ "pages/tasks/index", "pages/create/index", "pages/stats/index", "pages/profile/index" ], "window": { "navigationBarTitleText": "WorkBuddy", "navigationBarBackgroundColor": "#2B7DE9", "navigationBarTextStyle": "white" }, "tabBar": { "color": "#999999", "selectedColor": "#2B7DE9", "backgroundColor": "#ffffff", "list": [ { "pagePath": "pages/tasks/index", "text": "待办" }, { "pagePath": "pages/create/index", "text": "新建" }, { "pagePath": "pages/stats/index", "text": "统计" }, { "pagePath": "pages/profile/index", "text": "我的" } ] } }

tabBar 的图标我一开始没有配，先让文字导航跑通。因为切图、压缩、适配这套流程会拖慢初期节奏，没有图标也能开发调试。但上线前必须补上，微信审核对空页面和明显缺失的视觉元素会判定为“体验不完整”。图标图片大小建议控制在 40KB 以内，使用 PNG 格式。尺寸不对或者过大，真机上图标会被裁切或导致启动变慢。

窗口配置里我把导航栏背景色改成了主蓝色，文字设为白色。这个操作不是必须的，但能让你在调试时更接近最终视觉，避免后期反复调样式。在开发阶段，你可以先关掉很多真实环境限制，比如不校验合法域名。这个选项在开发者工具右上角“详情-本地设置”里，开发时开着能让你在没有配置服务器域名的情况下直接调试接口，但发布前必须关掉并配置好真实域名。

3. 从空白页到核心功能

3.1 任务列表页：页面结构、渲染逻辑与状态切换

任务列表页是 WorkBuddy 的门面，也是我最先写的一个页面。页面骨架分三块：顶部标题、列表区域、空状态提示。早期我为了让列表好看，堆了很多嵌套的 view，结果真机上一屏只能显示两三条任务，滚动也不流畅。后来我把结构打平，功能卡片的层级尽量浅，性能问题立刻缓解。

WXML 结构大致这样：

<view class="container"> <view class="head"> <text class="title">今天要搞定这些事</text> </view> <block wx:if="{{loading}}"> <view class="state">加载中...</view> </block> <block wx:elif="{{taskList.length > 0}}"> <view wx:for="{{taskList}}" wx:key="id" class="task-card {{item.status === 'done' ? 'task-card--done' : ''}}" > <view class="task-main" bindtap="handleOpenDetail">const store = require('../../utils/store') Page({ data: { loading: true, taskList: [] }, onShow() { this.refresh() }, refresh() { const list = store.getTasks() this.setData({ taskList: list, loading: false }) }, handleToggleStatus(e) { const id = e.currentTarget.dataset.id store.toggleTask(id) this.refresh() } })

这里还有一个提升体验的点：操作完列表后不要直接整页刷新，先做局部状态更新再调refresh()会显得更顺。不过 MVP 阶段任务量不大，整页刷新并不会带来卡顿，真正要做性能优化时再精细化处理也不晚。

3.2 新增任务页与表单校验

新增页的难点不是表单 UI，而是校验逻辑。用户输入不可信，这句话在哪个平台都成立。我在新增页放过一个让人血压升高的 Bug：用户不填标题直接点保存，结果列表里出现一堆“未命名任务”，删都删不完。所以表单校验必须在前端拦住无效数据。

WorkBuddy 的新增页包含三个字段：任务标题、计划日期、备注。标题必填，日期默认选今天，备注可以为空。日期我用原生 picker 组件，mode 设为 date。

校验逻辑写在一个提交函数里：

handleSave() { const title = this.data.title.trim() const dueDate = this.data.dueDate if (!title) { wx.showToast({ title: '标题不能为空', icon: 'none' }) return } if (!dueDate) { wx.showToast({ title: '请选择日期', icon: 'none' }) return } const result = store.addTask({ title, dueDate, status: 'todo', remark: this.data.remark.trim(), createdAt: Date.now() }) if (result) { wx.showToast({ title: '已保存', icon: 'success' }) setTimeout(() => { wx.switchTab({ url: '/pages/tasks/index' }) }, 500) } }

这里我想强调一件事：校验逻辑不要只放在提交按钮里，还要在页面离开时做一次兜底。用户可以触发返回手势，也可以点左上角返回，如果你的校验只写在保存按钮上，用户就有机会绕过正常流程，把半成品数据带回上一页。我的做法是保存成功后直接跳回列表页，保存失败只弹 toast，不让用户带着脏数据回去。

另外，wx.switchTab只能用于跳转到 tabBar 页面，如果目标页面不在 tabBar 里，就要用wx.navigateTo或wx.redirectTo。我在第一次写这个功能时就因为用错 API 导致按钮点了没反应，排查了半天才发现是跳转方式用错了。

3.3 本地存储封装与数据持久化

任务数据不落盘就没有任何意义。微信小程序里最轻量的持久化方案是wx.setStorageSync，它把数据保存在本地缓存中，容量上限是 10MB。对于纯文本任务来说，这个量级足够了。我封装了utils/store.js，所有存储操作都走这个模块。

const TASK_KEY = 'workbuddy_tasks' function getTasks() { const list = wx.getStorageSync(TASK_KEY) return Array.isArray(list) ? list : [] } function saveTasks(list) { wx.setStorageSync(TASK_KEY, list) } function addTask(task) { const list = getTasks() const newTask = { ...task, id: Date.now().toString(36) + Math.random().toString(36).slice(2, 6) } list.unshift(newTask) saveTasks(list) return newTask } function toggleTask(id) { const list = getTasks() for (let i = 0; i < list.length; i++) { if (list[i].id === id) { list[i].status = list[i].status === 'done' ? 'todo' : 'done' break } } saveTasks(list) } module.exports = { getTasks, addTask, toggleTask }

为什么任务 ID 不直接用自增数字？因为本地删除和插入很容易导致 ID 冲突，用时间戳加随机数的组合基本不会重复，以后就算把数据同步到云端，也不会因为客户端生成的脏 ID 打架。

这个 store 模块接下来演化出几个派生函数：按日期筛选任务、统计完成率、清空数据。统计页的计算逻辑都基于这个 getTasks 接口，没有让页面直接读缓存。这是我做的第一个抽象边界，也是整个项目里性价比最高的一个决定。

3.4 远程接口封装与登录态的思考

WorkBuddy 第一版只有本地数据，但我知道它早晚要接后端，所以我把请求模块先写了，算是预埋。这个模块不需要很复杂，但一定要处理三个问题：统一错误码、携带 Token、处理登录失效。

function request({ url, method = 'GET', data }) { return new Promise((resolve, reject) => { wx.request({ url, method, data, header: { 'Content-Type': 'application/json', 'Authorization': 'Bearer ' + wx.getStorageSync('token') }, success(res) { if (res.statusCode === 200 && res.data.code === 0) { resolve(res.data.data) } else { if (res.statusCode === 401) { handleLoginExpired() } reject(res) } }, fail(err) { reject(err) } }) }) }

handleLoginExpired我做了两件事：清除 token，然后跳转登录页。很多开发者在 401 时只弹个 toast，但用户如果继续操作就会反复点击、反复报错，体验非常糟糕。

关于登录态，这里要特别提醒一个误区：wx.login拿到的是一个临时 code，不是用户身份凭证，code 必须发送到你的后端，由后端拿着 code 去微信接口换取 openid 和 session_key。如果你没有自己的后端，在小程序里直接调wx.login之后不要试图去拿 openid，那是无效且不安全的做法。WorkBuddy 目前不需要登录，这个设计本质上是在为以后增加多人同步、跨设备恢复数据做准备。提前搭好请求层，后面写业务时就不会到处散落请求代码。

4. 真机调试与上线前的那些坑

4.1 真机和模拟器的差异，比你想象的更大

我见过不少项目在模拟器里一切正常，一上真机就白屏、闪退、接口超时。模拟器能模拟大部分功能，但模拟不了真实网络环境、硬件能力、内存限制和微信版本差异。

开发 WorkBuddy 时，我在真机上踩过的坑有三个：

1. 日期选择器的显示层级问题。某些低版本基础库下 picker 弹层会被页面元素遮挡，需要把 picker 放在页面根部或者用z-index显式控制层级。

2. 缓存数据读取异常。真机上wx.getStorageSync返回值可能不是预期格式，如果存储了一个损坏的 JSON，Array.isArray(list)能帮你兜住这个错，让页面回退到空列表而不是直接崩溃。

3. 域名校验问题。真机预览默认不校验合法域名，但如果你开启了“开发环境不校验请求域名”后忘了关，真机上能请求到接口，到了体验版和正式版就全部失效。上线前一定记得在公众平台后台配置 request 合法域名，并且域名必须是 HTTPS，不能用 IP。

真机调试不是把手机连上电脑就完了，要做一次完整的流程测试：从新建任务到切换 tab 到杀掉小程序重开，确认数据还在。我自己的习惯是每天结束前手动清一次缓存，确保数据能正常恢复。

4.2 性能优化到这个程度就够了

小程序性能优化的核心指标是首屏渲染速度和页面切换流畅度。WorkBuddy 的数据量不大，所以我做的性能优化很简单，但每一件都管用：

• 不要一次渲染几千条任务列表。我用“今天待办”维度先过滤，默认只展示 20 条，超过 20 条按时间倒序分批加载。这个分页逻辑写在 store 里，页面只关注当前展示的列表。
• 避免频繁调用setData。一次循环里多次setData会让渲染线程反复请求，造成卡顿。我把所有要变更的数据先聚合到一个对象里，最后只调一次setData。
• 图片资源尽量压缩或使用云端 CDN。本地图标过大会拖慢包体积，小程序主包有 2MB 限制，超过了就得上分包。
• 对高频操作加防抖。比如用户快速点击多次保存按钮，会导致重复写入同一任务。我在保存函数里加了isSaving标志位，保存期间禁止再次提交。

这些优化做完了，一个工具类小程序的性能就足够了。不要一开始就上虚拟列表、WebView 混合渲染这类复杂方案，复杂度带来的维护成本会盖过性能收益。

4.3 提交审核前，我会拿着这张表自检

上线前不要直接点“提交审核”，先检查一遍。我给自己列了一张自检清单，每次发版本前都会过一遍：

审核最怕的不是功能少，而是页面空白。如果你提交一个空列表页面作为主页，审核人员会认为你在上新前的演示 Demo，不仅驳回，还会要求你补运营内容。WorkBuddy 的首页在无数据时会显示“还没有任务，去新建一个吧”，配合新建按钮，这就算不是空白页。

上线之前还要把开发者工具里的“域名校验”打开，重新在模拟器里跑一遍接口。发布后如果发现有紧急 Bug，可以在公众平台提交新版本，但微信审核需要时间，所以每次提交前测试越充分，你后面越省心。

5. 基于 MVP 的后续扩展思路

5.1 云开发：从本地数据到多端同步的自然过渡

WorkBuddy 目前用的是本地缓存，这意味着用户卸载小程序或者换手机，历史任务就全丢了。对个人工具来说，这还能忍，但要多人协同，就完全不够。

微信的云开发是我接下来准备接的下一步。云开发的数据库可以直接在 JS 里读写，不需要自己买服务器、配域名、做鉴权。原来的store.js不需要推翻，只需要把数据读写替换成云数据库的 CRUD，然后保持向页面暴露同样名字的接口，页面代码基本不用改，这一步就能看出当初封装 store 的价值。

云开发扩容也简单，免费额度对个人项目足够用。但要注意，云开发环境也要区分正式环境和测试环境，别把测试数据同步到生产库。

5.2 订阅消息和分享卡片，是工具类小程序增长的最小闭环

工具类小程序天然缺少社交传播力，但有一个解法是订阅消息。用户创建一项任务后，可以通过wx.requestSubscribeMessage请求一次订阅，然后在你指定的时间给他推送一条“你的任务要到期了”的提醒。这一个功能对日程类工具的留存帮助极大。

订阅消息在开发时有个需要优先了解的坑：用户授权一次只能发送一条模板消息，不能无限推送。你要在用户最需要的时机去请求授权，比如他刚创建任务的时候，而不是启动时直接弹窗，那会把用户吓跑。

分享功能也一样，我在任务详情页加了onShareAppMessage，把任务标题带进分享文案。别人打开分享卡片后，只看一眼就知道这个工具适不适合他，这种透传分享语的细节比写十页推广说明都有用。

5.3 把“完成”这个动作变成正向激励

WorkBuddy 的统计页目前在数据呈现上很朴素，只有几个数字。但我在迭代时发现，用户对“完成”本身的正反馈要求很高。所以我把任务列表里的“设为完成”按钮换成“打个勾”，并加了一个轻量动画；每当完成一条任务，统计页的数字立即变化。这个改动让用户愿意在一天内频繁打开小程序，去处理下一条任务。

这里我想分享一个小技巧：把数据变更后的视觉反馈做得即时且可感知，比任何复杂的排行榜都有效。WorkBuddy 没有做积分体系，没有做连续打卡，但靠这种微小的正反馈，就能让用户形成使用惯性。

6. 留给你的几个实现细节

6.1 页面栈管理：别把数据读写在跳转之间搞乱

你在跳转页面时，页面栈是有生命周期的。从一个 tab 页跳到另一个 tab 页，旧页面不会销毁，只会触发onHide。如果你在onHide里去读数据、清理状态，很容易造成前后台状态不一致。我的建议是：数据初始化集中在onShow，状态清理放在onUnload或组件销毁钩子里，中间不要横生枝节。这样调试时大脑有一套清晰的预期，不会在排查问题时“咦，为什么这个地方的数据变了”。

6.2 格式化时间不要自己造轮子

统计页需要按日期分组，新增页需要默认今天的日期，任务列表页需要显示时间。这几个场景都需要时间格式化。我在第一版里顺手写了一个日期格式化函数，自以为没问题，结果真机上测试时发现时区加上new Date('YYYY-MM-DD')的解析差异，日期会偏移一天。后来我直接改用wx.getStorageSync存 timestamp，需要用日期展示时再单独转换。有现成工具库就用工具库，没有的话只处理你已知的格式，不要试图写一个通用日期引擎。

6.3 写代码前先给项目定一套自己说了算的命名规范

小程序项目最容易乱的地方是文件命名和页面路由。WorkBuddy 的页面名从一开始就用全小写加横杠，比如task-list、create-task。资源文件、工具函数也都按职责划分目录。这种规范会让你三周后再打开项目，不需要大量注释就能快速定位文件。别小看这件事，很多项目后期改版，最大的成本不是写新功能，而是在旧代码里挖数据流。

我在最后想单独聊两句个人体会。开发 WorkBuddy 最大的收获，不是代码跑通那瞬间的兴奋，而是它让我重新理解了“最小可用”这四个字。我以前很容易陷入“多做一点”的心态，总想在这个页面加个花哨动画，在那个页面塞更多功能。但真正把一个工具做到让人愿意天天打开，靠的恰恰是把核心操作做得足够顺滑。WorkBuddy 现在能让我在 10 秒内记录一条任务，在一天结束后快速回顾当天成果，我就觉得这个项目已经完成了它本该完成的事。如果你也在做同类型的小工具，我建议你先别急着堆功能，把列表、保存、读取、刷新这条主链路打磨到不需要思考就能操作，再把别的环节一点点加进来。上线之后你回头看，一定会感谢当初那个懂得收手的自己。