简介这是一份面向中医交流场景的微信小程序完整源码适合中医爱好者、内容运营者以及小程序初学者学习参考。项目围绕中医咨询、内容分享与互动交流展开实现了评论、点赞、视频浏览等常见社区功能。压缩包共110个文件主要包含js逻辑脚本、json配置、wxml页面结构、wxss样式以及png图片资源另附md说明文档和gif演示动图整体大小1.58MB目录划分清晰便于按模块查看。已有650人学习下载。源码覆盖index首页、find发现、detail详情、chatroom聊天室、publish发布、my个人中心等页面可帮助读者理解小程序页面路由、数据交互、列表渲染和组件化开发思路同时为搭建中医资讯或轻社交类小程序提供可直接改造的基础。1. 从一份中医咨询源码包到可运行的微信小程序拿到一份“中医咨询交流微信小程序源码.zip”多数人第一步不是解压看代码而是先想清楚一件事这个包解出来之后我要怎么把它跑起来再改成自己的东西。这个标题里最值钱的信息其实不是“源码”本身而是“中医咨询交流”这几个字——它意味着你要面对的是一套包含在线问诊、辨证分型、健康档案、医患消息在内的小程序绝不是简单的展示页。做这类项目核心难点有三个一是中医领域的知识结构怎么建模比如“证型”“体质”“方剂”不是简单的标签而是多层嵌套的数据关系二是咨询交流场景下的消息协议怎么设计文本、图片、处方卡片要有统一的消息格式三是微信小程序本身的限制——包体积、审核规范、用户隐私授权都会左右你的架构选择。这篇文章按我从拿到源码包到上线维护的完整思路来写。新手可以跟着每一步把项目跑通熟手可以直接跳到参数配置和数据模型部分对照着检查自己的实现有没有踩坑。配合近期大家普遍关心的微信小程序开发、uniapp 跨端、源码包部署等话题我会把关键的代码结构和配置逐段拆开讲不绕弯子。2. 解压与工程结构先看懂源码包里的中医小程序长什么样2.1 用 uniapp 还是原生微信小程序从源码包的第一层目录判断解压源码包之后不要急着打开编辑器先在根目录看一眼文件结构。常见的中医咨询交流小程序源码包会有两种组织方式原生微信小程序工程或者 uniapp 工程。原生微信小程序工程的最外层目录一般是pages/、app.js、app.json、app.wxss整个项目直接面向微信开发者工具。这种结构的优点是运行时行为最接近真机调试直观缺点是如果你以后想同时上线支付宝小程序或者 H5代码迁移成本很高。uniapp 工程则会有src/或pages/目录、manifest.json、pages.json、main.js。我一般会优先推荐用 uniapp 跑这类源码原因不只是跨端更是因为 uni-app 的pages.json对导航栏、tabBar、分包的管理方式比原生的app.json更集中尤其适合中医问诊这种页面多、角色多的项目。判断方法很简单用 HBuilderX 打开项目根目录如果能识别出manifest.json且提示“导入 uni-app 项目”就是 uniapp如果只能在微信开发者工具里打开且根目录直接出现app.json就是原生小程序。2.2 页面划分与分包策略问诊、辨证、档案、消息四个核心模块不管源码的结构怎么变一个完整的中医咨询交流小程序至少要拆出这几个页面模块。模块核心页面职责问诊模块问诊单填写、辨证结果页、方剂推荐页采集症状、舌苔、脉象等四诊信息输出证型判断咨询模块咨询会话列表、聊天窗口医患双方实时或异步消息档案模块体质档案、历史问诊记录管理用户多次问诊的纵向数据个人中心用户信息、收藏、订单基础账号体系与支付入口我见过的源码包如果分包做得好会在pages.json里把问诊流程页放在主包把咨询聊天页和技术文档页放分包。原因是聊天页面往往附带图片上传、录音等组件体积偏大问诊表单是用户必经路径放主包保证秒开。这个“访问频次优先”的分包原则在任何源码改造中都成立。{ pages: [ pages/index/index, pages/diagnosis/form, pages/diagnosis/result ], subPackages: [ { root: pkg-chat, pages: [ pages/chat-list/chat-list, pages/chat/chat ] }, { root: pkg-profile, pages: [ pages/archive/archive, pages/records/records ] } ] }分包配置里有三个点容易被忽略。一是root字段不能以/开头否则真机上会报路径解析失败二是分包之间的页面跳转要用绝对路径比如/pkg-chat/pages/chat/chat?doctorIdxxx不能用相对路径三是主包和分包的总大小不能超过 2M如果源码包解出来比较大优先压缩的是图片资源和聊天页的第三方组件不是 JS 逻辑代码。2.3 全局配置与导航栏修改刚进入的加载页面和顶部导航高度打开app.json或pages.json你会看到pages数组里的第一项就是小程序冷启动后加载的页面。源码包里这个页面往往叫pages/index/index但如果原作者把第一个页面设置成了某个活动页或者广告页你需要自己改回落地页。修改刚进入的加载页面时除了调整pages数组顺序还要注意window配置里的导航栏参数。中医问诊的场景里很多页面有自定义顶部导航比如聊天页要显示“医生在线”状态、辨证结果页要显示分享按钮这时候需要把navigationStyle设为custom。{ window: { navigationBarBackgroundColor: #F5F6F7, navigationBarTitleText: 中医咨询, navigationBarTextStyle: black, navigationStyle: custom, backgroundColor: #F5F6F7 } }导航栏改成 custom 之后一个高频坑立刻出现状态栏高度。iPhone 的刘海屏和普通安卓机的状态栏高度不一样如果页面内容从顶部开始布局内容会被状态栏遮住。我常用的做法是封装一个获取状态栏高度的工具函数在onLoad里拿到高度后动态设置占位 view。const getStatusBarHeight () { const systemInfo wx.getSystemInfoSync() return systemInfo.statusBarHeight || 20 } export default { data() { return { statusBarHeight: 20 } }, onLoad() { this.statusBarHeight getStatusBarHeight() } }补充一个容易踩的暗坑如果把navigationStyle设为customwx.setNavigationBarTitle就不再生效页面标题需要你自己在自定义导航栏里用数据渲染。这也是很多源码包里“标题不显示”问题的根因排查时先看是不是全局配置了 custom 导航再看页面里有没有取到标题字段。3. 辨证与问诊流程把中医知识结构转成小程序的数据模型3.1 证型、体质、方剂的三层数据关系中医咨询交流小程序和普通医疗咨询应用最大的区别在于数据模型不是“用户-医生-对话”的三元关系而是“用户-证型-体质-方剂-医嘱”的多层嵌套关系。源码包里一般会内置一套这样的数据表或 JSON 文件。我拆过几个类似的项目比较合理的数据结构是分三层第一层是基础档案层记录用户的基本信息和主诉症状第二层是辨证层存放四诊数据望闻问切和判断出的证型第三层是干预层存放方剂推荐、穴位按压建议、生活调理方案。实际落地时不需要一开始就把三张表全部做实。小程序的存储空间和读取性能都有限我一般会把这套关系建模成 MySQL 关联表加 redis 缓存的组合代码如下面这样。对于源码包自带的本地 JSON 数据则负责前端页面的静态展示和开发环境自测用途。CREATE TABLE syndrome ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) COMMENT 证型名称如肝气郁结, parent_id INT DEFAULT 0 COMMENT 上级辨证分型, surface TEXT COMMENT 主症描述, tongue TEXT COMMENT 舌象特征, pulse TEXT COMMENT 脉象特征, confidence_min DECIMAL(3,2) COMMENT 置信度阈值下限 ); CREATE TABLE prescription ( id INT PRIMARY KEY AUTO_INCREMENT, syndrome_id INT COMMENT 关联证型, name VARCHAR(100) COMMENT 方剂名, ingredients TEXT COMMENT 药材组成, dosage TEXT COMMENT 剂量说明, decoction_method TEXT COMMENT 煎服法 );这个模型的关键在于syndrome表没有做完全的扁平化而是用parent_id支持证型嵌套。比如“肝气郁结”是“气滞”的子类“气滞”又是“实证”的子类。问诊算法做推理时可以按照层级从宽到窄筛选最差也能给用户一个大致方向避免因为某一项症状不匹配就完全无法给出建议。3.2 四诊信息的结构化采集症状、舌象、脉象的输入设计问诊表单是辨证流程的数据入口。中医四诊里“望”看舌象和面色“闻”听声音和气味“问”是症状询问“切”是脉象其中“问”是结构化程度最高的也是小程序表单能采集最多的。源码包里通常已经写好了表单页但字段设计往往有两类问题。一类是选项粒度太粗比如“舌苔白腻”和“舌苔薄白”混在一个选项里另一类是单选和多选混用导致后端拿到的数据语义不清。我改造问诊表单时通常采用三步第一步把四诊字段分成四组舌色、苔色、苔质、脉象。每组下设可选项允许多选但限制最多选 3 项。第二步每组字段设置“不确定”选项作为算法的兜底输入。第三步提交时把表单数据组织成结构化对象由“症状”转入“证型”的核心推断逻辑去处理。// 问诊表单提交数据结构 const formData { tongueColor: [淡红], // 舌色 tongueCoating: [薄白], // 苔色 coatingQuality: [腻], // 苔质 pulse: [弦], // 脉象 symptoms: [ { name: 胁肋胀痛, severity: 中度, duration: 2周 }, { name: 情绪低落, severity: 轻度, duration: 1个月 } ], questions: { thirst: 口苦咽干, appetite: 食欲不振, sleep: 入睡困难, stool: 大便偏干 } }这里的核心设计是symptoms用了数组结构每一项包含症状名、严重程度和持续时间。原因在于同一种症状在不同患者身上的权重完全不同——同样是胁肋胀痛持续 2 周和持续 2 年的辨证权重不能一样算法需要这些字段做加权。源码包里如果只保留字符串类型的主诉后端拿到之后只能做关键词匹配辨证准确性会大打折扣。3.3 辨证结果的展示与置信度控制不做百分百的确定性断言小程序里展示辨证结果时一个常见的产品决策是是否给出“确定”的结论。我的建议是源码改造时一定要加上置信度机制用“倾向”“可能”这类措辞配合一个百分比区间展示给用户。// 辨证结果展示数据 const diagnosisResult { syndrome: { name: 肝气郁结, confidence: 0.78, level: high }, alternatives: [ { name: 肝郁脾虚, confidence: 0.15 }, { name: 气滞血瘀, confidence: 0.07 } ], recommendation: { prescription: 逍遥散加减, acupoints: [太冲, 期门, 膻中], lifestyle: 适当运动调畅情志 } }置信度计算的核心算法思路不复杂每个症状对应到证型的映射表里有一个权重分把用户勾选的症状权重全部累加再做归一化得到每个候选证型的得分。展示时把最高分作为第一诊断其余作为备选。这个做法在工程上成本低但能极大降低问诊结果的争议风险。confidence字段的数据要进行口径确认不同源码包对置信度的定义不同有的直接存百分比数字有的是两位小数。我一般在展示层统一乘以 100 再拼接百分号并且对 0.6 以下的结果只显示“辨证趋向”不显示具体证型名避免用户误读。4. 咨询会话与消息列表让医患双方在微信小程序里稳定交流4.1 消息通道选型WebSocket 长连接还是半轮询中医咨询交流场景下的消息和普通客服消息有一个显著不同中医的消息里包含大量的结构化卡片——辨证结果、处方、穴位图。这意味着消息协议不能光传文本要有类型区分和渲染机制。先用常见方式来实现微信小程序原生提供wx.connectSocket接口可以直接建立 WebSocket 长连接。源码包如果自带聊天页第一步就是看它使用的是原生wx.connectSocket还是接入第三方即时通信 SDK。前者代码量少但要做好断线重连、心跳检测后者稳定但会引入较大依赖包体积。我处理的源码包多数用的是原生 WebSocket所以我会重点讲这个路径。小程序端的 WebSocket 连接代码通常封装在utils/socket.js里核心代码长这样// 小程序端 WebSocket 封装简化版 let socketTask null let heartbeatTimer null let reconnectCount 0 function connectSocket(wsUrl, token) { socketTask wx.connectSocket({ url: ${wsUrl}?token${token}, success: () console.log(WebSocket 连接发起), fail: (err) console.error(连接失败, err) }) socketTask.onOpen(() { console.log(WebSocket 已建立连接) startHeartbeat() }) socketTask.onMessage((response) { const data JSON.parse(response.data) handleMessage(data) }) socketTask.onClose(() { console.log(WebSocket 连接关闭) reconnect() }) socketTask.onError((error) { console.error(WebSocket 连接错误, error) reconnect() }) } function startHeartbeat() { heartbeatTimer setInterval(() { socketTask.send({ data: JSON.stringify({ type: ping, timestamp: Date.now() }) }) }, 30000) } function reconnect() { if (reconnectCount 5) return setTimeout(() { reconnectCount connectSocket(wsUrl, token) }, 1000 * Math.pow(2, reconnectCount)) }这段代码里有两个参数值得关注。第一是心跳间隔 30 秒微信小程序在部分安卓机上会主动回收空闲 60 秒的长连接心跳必须短于这个回收时间。第二是断线重连的退避算法指数退避比固定时间重连要可靠得多——但在弱网环境下重连次数超过 5 次后我会干脆引导用户走小程序客服消息的兜底通道而不是无限重连。4.2 消息结构与渲染用消息类型字段区分文本、图片和处方卡片聊天数据格式的设计决定了后续所有功能的扩展空间。我把中医咨询小程序里的消息类型归纳为五种文本text、图片image、辨证结果卡片diagnosis_card、处方卡片prescription_card、系统提示system。每条消息至少携带 8 个字段{ msgId: wx_20250314_001, conversationId: doc_101_user_2025, senderId: doc_101, senderType: doctor, msgType: prescription_card, content: { text: 根据你的情况建议服用以下方剂, prescription: { name: 逍遥散加减, ingredients: 柴胡、当归、白芍、白术、茯苓、炙甘草、薄荷、生姜, dosage: 每日一剂水煎服早晚各一次, duration: 7 天 } }, timestamp: 1710422400000, status: sent }msgType是渲染分发的核心聊天页拿到消息后先判断msgType再决定走哪一套 UI 模板。把辩证结果和处方做结构化的消息卡片而不是拼在文本里还有一个实用好处用户以后可以在“历史记录”里直接按压处方卡片保存图片不需要重新翻聊天记录。你可以在源码包的聊天页wxml中找到类似wx:if{{ item.msgType prescription_card }}的模板分支。4.3 长按拖拽滚动与消息加载优化聊天页面的交互细节聊天页面里有一个容易被忽视的交互用户在浏览历史消息时因为流式渲染导致页面抖动手指拖动时消息列表不能流畅跟随。优化方向是两点滚动位置锚定和渲染数量控制。第一点渲染控制。一次性把整个对话历史塞入setData会让小程序页面卡死。比较稳妥的做法是分页加载每次加载 20 条配合scroll-view的scroll-top控制滚动位置。// 分页加载历史消息 const pageSize 20 Page({ data: { messages: [], scrollTop: 0 }, onLoad() { this.loadMessages(0) }, loadMessages(offset) { const db wx.cloud.database() db.collection(messages) .where({ conversationId: this.conversationId }) .orderBy(timestamp, desc) .skip(offset) .limit(pageSize) .get() .then((res) { const oldMessages res.data.reverse() this.setData({ messages: oldMessages.concat(this.data.messages), scrollTop: 0 }) }) } })scrollTop: 0在向上翻页时会跳转到消息列表顶部这个在数据量小的时候会跳不到准确位置。更精细的做法是用wx.createSelectorQuery获取消息列表节点高度在setData之后执行wx.pageScrollTo按新增消息的高度做位移补偿。因为消息高度不一致后端需要在消息里带上预估高度源码包里这一步大多省略你可以根据页面的实际卡顿程度决定要不要补。4.4 保存附件到本地wx.env.user_data_path 与附件缓存策略聊天里医生发的辨证报告、处方笺图片用户希望保存到手机相册或者本地缓存。微信小程序有wx.env.user_data_path这个用户数据目录可以用来存放用户文档。在做“保存附件”功能时我的实现思路是先把网络图片下载到本地再保存或者做成本地持久化缓存路径。const UserDataPath wx.env.USER_DATA_PATH || wx.env.user_data_path const saveAttachment (fileUrl, fileName) { const localPath ${UserDataPath}/${fileName} wx.downloadFile({ url: fileUrl, success: (res) { if (res.statusCode 200) { wx.saveFile({ tempFilePath: res.tempFilePath, success: (saveRes) { wx.setStorageSync(attachment_ fileName, saveRes.savedFilePath) wx.showToast({ title: 已保存到本地 }) } }) } } }) }这里有一个注意点wx.env.USER_DATA_PATH和wx.env.user_data_path在不同基础库版本下写法不同旧版用USER_DATA_PATH全大写新版兼容小写。源码包如果是老版本可能会在低版本基础库上偶发路径不识别的问题建议两个字段都兼容并优先使用wx.env.USER_DATA_PATH让新版 SDK 自动识别。5. 用户数据安全与平台规范中医小程序上线的两个必要检查5.1 健康数据脱敏与展示限制小程序涉及中医咨询其中问诊信息属于敏感健康数据。微信平台对这类小程序有严格的要求常见红线是不能在小程序端明文展示用户的完整身份证号、手机号、详细住址等。源码包只要涉及用户档案第一件事就是检查是否有敏感信息泄露。我一般会在前端做三层脱敏。第一层接口返回时去除敏感字段第二层展示层用掩码处理如138****8888第三层在wxml里对身份证、地址等字段直接不渲染后端不下发就能躲避大部分问题。如果源码包里后端接口结构已经定型不方便大改也可以在前端app.js全局封装一个脱敏工具函数在setData前统一处理数据。const desensitize (data) { if (data data.phone) { data.phone data.phone.replace(/^(\d{3})\d{4}(\d{4})$/, $1****$2) } if (data data.idCard) { data.idCard data.idCard.replace(/^(.{4}).*(.{4})$/, $1********$2) } return data }这段代码对展示层数据做了兜底处理。建议在utils目录下新建security.js统一维护这种函数不要散落在各个页面里这也是源码包内容迭代时最容易产生遗漏的位置。5.2 问诊内容的禁用词设置与平台审核医疗类小程序是微信内容审核的重点对象。除了不能出现“治疗”“痊愈”“根治”等绝对化用语外中医类目还有一个特殊约束不能脱离医生进行处方推荐。源码里如果在辨证结果页直接展示“建议服用这一方剂”审核大概率不会通过。建议的合规做法是问诊结果页只展示“辨证参考”和“体质分析”具体的方剂和用量只在经过医生确认后的咨询对话中出现。所以源码里你可能会看到diagnosis_result页有一个“提交给医生确认”的按钮就是这个原因。5.3 使用云开发还是自建后端数据权限与访问控制判断源码包的存储方案有两种情况一种是接微信云开发wx.cloud.database()一种是自建 HTTP API。前者天然集成用户身份系统数据权限可以用安全规则控制后者在小程序端需要自行管理 token 和用户身份。对于健康数据我更倾向云开发方案因为它可以直接配置“仅创建者可读写”的权限规则避免后端遗漏鉴权。在云开发控制台里设置数据权限时一个很容易出错的点是集合的“安全规则”和“权限设置”是分开配置的。问诊记录集合需要配置这样的规则这表示只有创建者本人可以读取自己的问诊记录{ read: auth.openid doc._openid, write: auth.openid doc._openid }如果源码包是自建后端你就需要在每个涉及个人健康数据读取的接口中校验 token并在app.js里做登录态守卫。很多自建后端源码会漏掉对医生端和用户端的数据越权校验比如用户 A 的 token 去请求用户 B 的问诊档案这种漏洞代码审查时一定要仔细过滤。6. 部署与验证让源码包在小程序后台安全跑起来信息确认做完之后用微信开发者工具导入源码包工程。导入时选择“小程序”而非“小游戏”AppID 建议先用测试号跑通流程避免开发阶段频繁改动真实 AppID 触发隐私校验。导入完成后首先操作的是在app.js里检查wx.cloud.init的env参数替换成自己开通的云开发环境 ID。wx.cloud.init({ env: your-cloud-env-id, traceUser: true })随后在云开发控制台创建users、doctors、messages、diagnosis_records四个基础集合并导入源码包里自带的 JSON 种子数据。这里注意导入时选择“冲突处理模式-插入”不要选择“替换”避免集合内已有用户数据被清空。业务开发完成后在开发者工具里点击“上传”版本号建议从 1.0.0 起步。提交审核前有一项必操作在「小程序后台-开发-开发设置-服务器域名」里将 WebSocket 域名和 HTTPS 域名加入白名单否则真机调试时会报url not in domain list。上线后的验证环节我习惯优先测试三个场景新用户首次进入需完整走一遍微信授权、手机号绑定、创建档案流程聊天页弱网下的消息重连与补发断网 15 秒再恢复处方卡片的保存到本地功能在安卓和 iOS 双端的表现差异。最后把整个项目目录压缩成新的中医咨询交流微信小程序源码.zip作为备份保存到网盘或本地磁盘同时把云开发数据库定期用「导出-定时导出」功能备份到对象存储防止后续开发导致数据环境污染。顺着这套路径从 zip 包到可稳定运行的小程序需要的周期通常不会超过两周。本文还有配套的精品资源点击获取