企业官网建设流程全解析

简介：基于微信小程序的智慧社区管理源码，面向物业与业主用户，覆盖公告、活动、投票、报事报修、房屋出租及个人管理等高频社区事务，可有效提升社区服务响应效率。系统采用客户端/服务器架构，并借助微信云开发实现后端存储与业务逻辑，适合有基础的小程序开发者学习云开发，也可用于高校课程设计。资源包共554个文件，约13.16MB，含201个JS脚本、106个WXSS样式、89个WXML模板、85个JSON配置、60个PNG图片及少量文档。各类文件分工明确：JS处理交互与请求，WXML和WXSS构建页面结构与视觉，JSON设定全局参数，图片提供界面素材，整体模块化程度高，便于按功能块研读。已有465人学习下载。源码可直接运行，后台首页、报事报修管理等核心模块齐全，配套开发文档和图片素材，能帮助快速理解智慧社区的业务流程、云函数调用及前后端数据交互，适合希望以真实项目为参考快速上手微信云开发的开发者。

1. 从 0 到 1 的智慧社区小程序：这份源码到底解决什么

我看到很多开发者把“基于微信小程序的智慧社区管理小程序设计源码”当成一套页面模板来用，改改名字、换换轮播图就以为完事了。但真实社区里，住户绑定、访客通行、报修工单、公告触达，任何一条链路没走通，用户都会觉得这是个假小程序。这套源码真正能帮你的，是把社区业务抽象成清晰的模块和表结构，再让微信登录、表单提交、云函数这些环节能连起来跑。它适合三类人：接社区物业项目的开发、做毕业设计的学生，以及想在小程序源码基础上二次开发的人。前提是你愿意先理解数据怎么流动，而不是直接换皮。

2. 需求拆解：把社区业务拆成四个域，再定数据模型

2.1 住户、访客、报修、公告：四个核心域的边界划分

拿到源码第一步不是看页面，而是看目录里有哪些模块。常见的智慧社区小程序至少包含住户、访客、报修、公告四个域。住户域管身份和房屋绑定，访客域管临时通行，报修域管工单流转，公告域管信息触达。很多翻车项目把“投诉”和“报修”混在同一个入口，导致工单状态机对不上。报修有明确的“待派单 / 处理中 / 待验收 / 完成”流程，投诉没有；所以至少要用一个 type 字段区分，而不是另起一套逻辑。房屋绑定也不要做成简单的文本输入，后端必须校验楼栋单元房间是否存在，否则会出现“10 号 3 单元 201”和“10-3-201”两种写法，统计时就乱了。

模块边界定了以后，权限也就清楚了：住户只能看自己楼栋的公告和提交与本房相关的报修；物业端能看到全部工单但看不到访客二维码的长期凭证。这些约束写进数据模型的 role 字段和查询条件，比前端做一堆 v-if 更可靠。

2.2 数据库设计：用 SQL 建出可扩展的 6 张核心表

不管最终用 MySQL 还是云开发集合，我都建议先把表结构画出来。下面是社区管理最小可用的 6 张表：用户、房屋绑定、报修工单、访客、公告、缴费。

-- 用户表，绑定微信身份和角色 CREATE TABLE t_user ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, openid VARCHAR(64) NOT NULL UNIQUE COMMENT '微信小程序唯一 openid', nick_name VARCHAR(64) DEFAULT '' COMMENT '昵称', phone CHAR(11) DEFAULT '' COMMENT '手机号，认证后回填', role TINYINT NOT NULL DEFAULT 0 COMMENT '0:住户 1:物业 2:访客', community_id INT UNSIGNED NOT NULL DEFAULT 0 COMMENT '所属社区', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_community (community_id) ) COMMENT='社区用户基础表'; CREATE TABLE t_household ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, user_id INT UNSIGNED NOT NULL COMMENT '绑定用户', building_no VARCHAR(16) NOT NULL COMMENT '楼栋号，如 10', unit_no VARCHAR(8) NOT NULL COMMENT '单元号', room_no VARCHAR(16) NOT NULL COMMENT '房间号', audit_state TINYINT NOT NULL DEFAULT 0 COMMENT '0待审核 1通过 2拒绝', bind_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) COMMENT='住户与房屋绑定表'; CREATE TABLE t_repair ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, user_id INT UNSIGNED NOT NULL, handle_no VARCHAR(24) NOT NULL COMMENT '工单号，如 R202406010001', type VARCHAR(20) NOT NULL COMMENT '水/电/门禁/其他', summary VARCHAR(255) NOT NULL, image_id VARCHAR(255) DEFAULT '' COMMENT '图片fileID', state TINYINT NOT NULL DEFAULT 0 COMMENT '0待派单 1处理中 2待验收 3完成 4取消', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP, KEY idx_user (user_id), KEY idx_state (state) ) COMMENT='报修工单表'; CREATE TABLE t_visitor ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, house_id INT UNSIGNED NOT NULL COMMENT '被访房间', visitor_name VARCHAR(32) NOT NULL, visitor_mobile VARCHAR(20) NOT NULL, visit_time DATETIME NOT NULL COMMENT '计划到访时间', qrcode_url VARCHAR(255) NOT NULL COMMENT '二维码图片或token', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待入场 1已入场 2已过期 3已取消', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) COMMENT='访客登记表'; CREATE TABLE t_notice ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, title VARCHAR(64) NOT NULL, content TEXT NOT NULL, cover_url VARCHAR(255) DEFAULT '' COMMENT '封面图', top_flag TINYINT NOT NULL DEFAULT 0 COMMENT '是否置顶', publish_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) COMMENT='社区公告表'; CREATE TABLE t_payment ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, house_id INT UNSIGNED NOT NULL, project VARCHAR(32) NOT NULL COMMENT '物业费/水费/停车费', amount DECIMAL(10,2) NOT NULL, due_date DATE NOT NULL COMMENT '缴费截止日', pay_state TINYINT NOT NULL DEFAULT 0 COMMENT '0未缴 1已缴 2逾期', pay_time DATETIME DEFAULT NULL, KEY idx_house (house_id) ) COMMENT='社区缴费表';

t_user 的 openid 列设为唯一索引，一个小程序账号对应一个用户，这里不能允许重复。role 字段不要用字符串，用 TINYINT 存数字，后续加角色只加枚举值，不用改表结构。t_household 里 audit_state 是房产认证的关键字段，用户填了房号并不代表是住户，需要物业在后台审核通过后，小程序才会把这个房子挂到用户名下。t_repair 的 handle_no 看起来是冗余字段，实际上非常有用，打印工单、跨系统对账时都靠它，不要在页面里用自增 id 给人看。t_visitor 的 qrcode_url 写的是二维码图片或 token，实际落地时更推荐存一个随机 token，原因是二维码图片本质上是个 URL，可以被截图传播，而 token 可以被门禁端校验有效期和状态，撤销访客时也方便。t_payment 的 amount 用 DECIMAL(10,2)，不要用 FLOAT，不然账单上会出现 0.8999999 这类浮点误差。

2.3 数据访问层的取舍：直接读库还是走云函数

很多开源版本会把数据库操作直接扔在小程序前端。好处是代码少，坏处是权限难控制。比如云开发数据库默认的权限规则里，客户端只能读自己创建的数据；公告是物业创建的，住户端直接读就变空白。所以我的推荐是：公告、报修列表这些只读场景，可以用云开发数据库的前端读，但要改集合权限；凡是写入操作，都包一层云函数。云函数运行在云端，拿到的是可信的用户身份 openid，可以自己写业务校验，而不是依赖前端的参数。自建后端也是同样的道理，客户端请求只负责传递数据，真正的状态流转放在服务端代码里。

如果你用自建后端，前端把 wx.login 返回的 code 传过去，后端再去微信接口换 openid；如果你用云开发，云函数里直接读 cloud.getWXContext().OPENID，这一步省了 code 交换。两种方式都会在第三章的代码里体现。

3. 源码骨架：全局配置与微信登录的落地姿势

3.1 从 app.json 到工具面板：一份能少走弯路的全局配置

先把手里的源码在微信开发者工具里跑起来。新建项目的时候不要选“空目录”，直接把源码目录放进去。如果源码里没有 node_modules，先执行 npm install，然后再用工具里的“构建 npm”。我第一次拿到这种项目时，直接点编译，结果一堆 require 报错，后来才想到微信小程序的 npm 构建不是自动的。

{ "pages": [ "pages/index/index", "pages/repair/index", "pages/visitor/index", "pages/payment/index", "pages/mine/index" ], "window": { "navigationBarTitleText": "智慧社区", "navigationBarBackgroundColor": "#2f6bff", "navigationBarTextStyle": "white" }, "tabBar": { "color": "#9aa5b4", "selectedColor": "#2f6bff", "list": [ { "pagePath": "pages/index/index", "text": "首页" }, { "pagePath": "pages/repair/index", "text": "报修" }, { "pagePath": "pages/mine/index", "text": "我的" } ] }, "permission": { "scope.userLocation": { "desc": "用于展示社区周边和访客导航" } } }

app.json 是全局配置，pages 数组第一项是启动页。tabBar 的 list 最多 5 项，低于 2 项不显示；这里最少需要三个入口。navigationBarTextStyle 只支持 black 和 white，不要改成其他颜色。permission 字段是给 wx.getLocation 用的，智慧社区涉及门禁和访客导航，没有这个声明，真机上调用 getLocation 会直接失败。另外，navigationStyle 默认是 default，如果源码改成 custom，就会进入自定义导航，此时要处理顶部导航栏高度，这个坑在第 5 章细说。

3.2 wx.login 拿到 code 之后：云函数取 openid 与手机号解密的正确姿势

先看 app.js 里的云开发初始化。如果源码里没有这段，真机上所有数据库和云函数调用都会报“Cloud API isn't enabled”。

// app.js App({ onLaunch() { if (!wx.cloud) { console.error('基础库版本过低') return } wx.cloud.init({ env: '你的环境ID', traceUser: true }) }, globalData: {} })

env 必须是云开发控制台里的环境 ID，不是默认值；traceUser 会在数据库访问记录里带上用户标识，方便排查请求，生产环境可关。接下来是登录页。用云开发时，云函数不需要前端传 code，因为微信已经把调用者身份注入到云函数上下文里。

// pages/mine/login.js Page({ onLoad() { // 每次启动先检测本地 openid，重新登录时以服务端结果为准 this.reLogin() }, async reLogin() { try { const { result } = await wx.cloud.callFunction({ name: 'getOpenId' }) wx.setStorageSync('openid', result.openid) this.setData({ openid: result.openid }) } catch (e) { wx.showToast({ title: '登录失败', icon: 'none' }) } }, // 手机号按钮 onGetPhone(e) { if (e.detail.errMsg !== 'getPhoneNumber:ok') return wx.cloud.callFunction({ name: 'decryptPhone', data: { code: e.detail.code } }).then(() => { wx.showToast({ title: '手机号已保存' }) }) } })

对应云函数：

// cloudfunctions/getOpenId/index.js const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) exports.main = async () => { const { OPENID, APPID } = cloud.getWXContext() return { openid: OPENID, appid: APPID } }

注意：不要把 wx.login 的 code 存进 storage 当登录凭据，它是短时凭证，只能换一次。

wx.login 通常在上述云开发流程里被自动处理，因为云函数已经带了调用者身份，不需要前端把 code 传上去。但如果你的后端不是云开发，那还是要 wx.login 拿到 code，再交给后端换取 openid。手机号获取必须用 button 的 open-type 触发，不能 onShow 里直接调；回调里的 e.detail.code 是动态令牌，用它去换手机号，换取一次就失效，所以不要缓存。之前看过有人把 e.detail.encryptedData 存进 MySQL，隔天解密全失败，因为 session_key 早就过期了。

4. 核心页面实现：公告轮播、报修提交与访客通行

4.1 首页公告轮播与动态数据绑定：wxml 里别堆逻辑

首页一般由轮播图、公告列表、快捷入口组成。公告列表不要写死，从集合 t_notice 查出来再渲染。

<swiper class="banner" indicator-dots autoplay circular interval="5000"> <block wx:for="{{banners}}" wx:key="id"> <swiper-item> <image src="{{item.cover_url}}" mode="aspectFill" class="banner-img" /> </swiper-item> </block> </swiper> <view class="notice"> <view class="notice-head"> <text class="notice-title">社区公告</text> </view> <view class="notice-item" wx:for="{{notices}}" wx:key="id"> <text class="notice-title">{{item.title}}</text> </view> </view>

const db = wx.cloud.database() const _ = db.command Page({ data: { banners: [], notices: [] }, async onLoad() { const notices = await db.collection('t_notice') .where({ publish_time: _.lte(new Date()) }) .orderBy('publish_time', 'desc') .limit(10) .get() this.setData({ notices: notices.data }) } })

_.lte(new Date()) 是为了只显示已发布的公告，避免定时公告提前泄漏。时间字段要保持类型统一，云开发里 Date 类型和字符串比较行为不同，如果之前在管理后台手工录了字符串，orderBy 的排序结果会不符合直觉。wxml 的 wx:key 不要用 index，用数据里的 id，否则列表重排后组件状态会串。banners 同理，建议从 t_notice 里取置顶公告或单独一个 banner 集合，不要写死图片地址。

4.2 报修表单的校验和提交：别让脏数据进工单表

报修页的表单大部分是 picker 选类型、textarea 写描述、上传图片。textarea 是原生组件，旧基础库上会被弹层遮挡，现在普通页面还好，如果遇到弹层，需要改用 view 模拟或使用同层渲染。表单提交逻辑如下：

// pages/repair/index.js const app = getApp() Page({ data: { repairTypes: ['水', '电', '门禁', '电梯', '其他'], typeIndex: 0, summary: '' }, onTypeChange(e) { this.setData({ typeIndex: Number(e.detail.value) }) }, onDescInput(e) { this.setData({ summary: e.detail.value.trim() }) }, async submitRepair() { const { repairTypes, typeIndex, summary } = this.data if (!summary || summary.length < 5) { wx.showToast({ title: '请至少写 5 个字', icon: 'none' }) return } wx.showLoading({ title: '提交中' }) try { await wx.cloud.callFunction({ name: 'repairCreate', data: { type: repairTypes[typeIndex], summary, houseId: app.globalData.houseId } }) wx.hideLoading() wx.showToast({ title: '已提交' }) this.setData({ summary: '', typeIndex: 0 }) } catch (err) { wx.hideLoading() wx.showToast({ title: '提交失败', icon: 'none' }) console.error('repairCreate failed', err) } } })

summary 要 trim 并做长度校验，这里定的是至少 5 个字，实际可以按项目调。houseId 必须来自登录后绑定的房间，不能允许用户手输；如果用户没有绑定房屋，后端应拒绝创建工单，前端也要提示先去“我的”页做房产认证。图片不要存入临时路径，要先上传云存储，第 5 章 5.5 会说。另外，云函数返回时要区分业务错误和系统错误，比如“该房间未绑定”应该返回 code 非 0，前端不要只看 HTTP 状态。

4.3 访客临时通行：二维码是令牌不是图片

访客的流程一般是：住户填写到访人电话和时间，生成一条访客记录，返回一个 token，前端用 token 和房间信息画二维码。门禁端扫码后，拿着 token 去查数据库，判断 status 和 visit_time 是否有效。

// cloudfunctions/visitorCreate/index.js const cloud = require('wx-server-sdk') const crypto = require('crypto') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db = cloud.database() exports.main = async (event) => { const { visitorName, visitorMobile, visitTime, houseId } = event if (!visitorName || !visitorMobile || !visitTime) { return { code: -1, msg: '参数不完整' } } const token = crypto.createHash('sha1') .update(`${visitorMobile}-${Date.now()}`) .digest('hex').slice(0, 16) const addRes = await db.collection('t_visitor').add({ data: { houseId, visitorName, visitorMobile, visitTime: new Date(visitTime), token, status: 0 } }) return { code: 0, visitorId: addRes._id, token } }

token 比二维码图片更适合作通行凭证。门禁机扫到二维码后解析出 token，再到数据库校验状态和有效期，过期时间直接看 visit_time，而不是生成时间，因为有的访客会提前一天登记。生产环境可以把 token 换成带签名的短字符串，但核心思路不变：不要暴露集合读写权限给门禁端，门禁端应该走一个单独查询接口。

5. 智慧社区小程序避坑：5 个让源码翻车的隐藏雷区

这章每一条都是实际跑社区项目时见过的问题。源码能编译通过，不代表能撑过一周的真机使用，下面这些坑最容易在验收前爆出来。

5.1 登录态失效却只刷新页面，没有刷新 openid

现象：开发时正常，第二天打开小程序页面卡在加载，重启开发者工具也没用。原因：wx.login 的 code 是短时凭证，有些源码把它存进 storage 当登录 token，用的时候已经失效；或者云函数环境 A/B 混用，本地 openid 和当前环境的 OPENID 不一致。解决：app.onLaunch 里每次重新调用登录，以服务端返回的 openid 为准；本地 storage 里的 openid 只当作缓存。实际调试时，打开开发者工具的“清除缓存 → 清除全部缓存”，再重新编译。

5.2 顶部导航栏高度写死，全面屏手机按钮被刘海遮住

现象：自定义导航头在 iPhone 上按钮贴到时间栏，Android 上又太高。原因：不同机型的 statusBarHeight 和胶囊高度不一样，写死 44pt 或 64px 都会错。解决：用 wx.getMenuButtonBoundingClientRect 动态计算。

// app.js App({ onLaunch() { const info = wx.getWindowInfo ? wx.getWindowInfo() : wx.getSystemInfoSync() try { const rect = wx.getMenuButtonBoundingClientRect() this.globalData.statusBarHeight = info.statusBarHeight this.globalData.navBarHeight = rect.top * 2 + rect.height - info.statusBarHeight } catch (e) { this.globalData.statusBarHeight = 20 this.globalData.navBarHeight = 44 } } })

rect.top * 2 + rect.height - statusBarHeight 是业界常用算法，算出来的是从顶到导航底的高度，页面里的导航组件高度直接绑定这个值。注意 wx.getSystemInfoSync 已被标记弃用，优先用 wx.getWindowInfo；模拟器和真机返回值可能不同，最终以真机为准。

5.3 云开发数据库的默认权限让公告和报修列表一片空白

现象：控制台能看到记录，小程序端加载出来 data: []，也没有报错。原因：云开发集合权限默认“仅创建者可读写”，物业在手机端创建的记录对普通住户不可见。解决：进入云开发控制台，选择集合，在权限设置里改成“所有用户可读，仅创建者可写”；如果走云函数读写，则可以选“仅管理端可写”。不要图省事把所有集合都设为所有人可写，因为报修里可能带门牌号，属于隐私。智慧社区的底线是：公告可公开读；报修、访客、缴费全部经云函数，函数内部校验权限。

5.4 云函数改了不生效，前端一直跑旧逻辑

现象：改完云函数，重新编译，调用的结果还是旧代码。原因：云函数文件改了但没有上传部署，或者云开发环境配错。解决：在开发者工具 cloudfunctions 目录右键目标函数，选择“上传并部署：云端安装依赖”。如果函数里新增了 npm 包，必须选这个选项；只改 js，也可以选“上传并部署：所有文件”。部署后，在开发者工具控制台点击“云函数”标签，能看到最近调用日志。还有一招：在云函数开头加一句 console.log 打印部署时间，看日志时间就知道自己调的是不是新代码。

5.5 图片临时路径直接入库，隔天列表就裂图

现象：报修时图片能上传，但第二天打开工单详情，所有图片打不开。原因：wx.uploadFile 返回的 tempFilePaths 只在本次小程序生命周期有效，存进数据库的不是永久存储。解决：先上传到云存储，把 fileID 存库。

async function uploadToCloud(tempFilePath) { const ext = tempFilePath.split('.').pop() || 'jpg' const cloudPath = `repair/${Date.now()}-${Math.random().toString(36).slice(2)}.${ext}` const res = await wx.cloud.uploadFile({ cloudPath, filePath: tempFilePath }) return res.fileID }

cloudPath 里要带随机段，否则两个用户同一毫秒上传同名文件会互相覆盖。展示时要用 wx.cloud.getTempFileURL 把 fileID 换成熟链，临时链接默认若干小时有效。大批量列表不要一张张在 wxml 里 bind，可以在云函数里一次性批量换取，再 setData 给前端。

6. 交付前收尾：验证清单、灰度习惯与我的调试顺序

6.1 三条核心链路真机自测

源码能跑不等于交付。我每次上线前会用体验版真机跑三条链路：住户认证、报修闭环、访客通行。下面是一张自测表，照着打钩比较稳。

这三条链路通了，其他页面基本不会出大问题。再拿体验版二维码发给物业和几位住户跑两三天，看云开发控制台里有没有超时的云函数。注意微信小程序认证费用和类目要提前问清：社区服务类目通常要求有营业执照，个人主体一般过不了审；如果只是给学校宿舍做内部演示，另说。

6.2 我的调试顺序：先通最小闭环，再谈样式

我自己吃过亏，拿到一份“智慧社区源码”第一件事就是改主题色和图片，结果登录和报修的问题拖到上线前一天才暴露。现在的顺序是：先关掉所有装饰性组件，跑通登录；再提交一条最小报修，看数据进到哪个集合；然后模拟住户和物业两个角色各走一遍流程。确认数据流没问题，才回去调导航栏、轮播动画。这个方法在看别人源码的时候尤其管用，因为你能分清哪些是核心业务，哪些是装饰。

最后说一句，智慧社区这种项目，难点从来不是页面写法，而是权限和状态。希望帮到你。

本文还有配套的精品资源，点击获取