企业官网建设流程全解析

1. 项目立项：先想清楚"科普系统"到底科普什么

接到这个需求的时候，甲方给的需求描述非常简单，"做一个中药材知识科普系统"，往细了问，对方也说不清楚具体要什么。这类项目最大的坑就在于"科普"两个字特别虚，你说它是个内容展示站也行，说它是百科查询工具也行，甚至还可能做成教学平台。所以真正动手写代码之前，我先花了一周时间把所有可能的需求场景列出来，跟对方反复确认，最终把产品边界锁死。

最终确认的产品定位是：面向普通用户，以中药材为核心线索，提供药材信息查询、性味归经科普、常见配伍展示、用药禁忌提示这样四类核心内容。用户群体锁定在养生爱好者、中医药专业学生、以及想了解中药材基础知识的普通大众，不做在线问诊，不做处方推荐，不做药材商城，这三个"不做"非常重要，既规避了监管风险，也砍掉了大量不必要的工作量。

从技术端看，微信小程序是这个场景比较合适的载体。用户不需要下载App，搜一下或者扫个码就能打开，对于"偶尔查一查药材信息"这种低频但刚需的使用场景来说，使用门槛足够低。微信生态自带的分享能力还能让用户把某一个药材的科普卡片直接转发到群聊或者朋友圈，这种传播方式是H5和App都比不了的。

产品边界确定之后，接下来就是功能模块的拆解。我当时画了一张很简单的功能脑图，分成四块：

• 首页：搜索入口、药材分类导航、今日推荐药材
• 分类页：按中药材的传统分类（解表药、清热药、补虚药等）浏览
• 详情页：药材图文介绍、性味归经、功效主治、用法用量、配伍禁忌、典型方剂
• 个人中心：收藏列表、浏览历史、意见反馈

这四块功能覆盖了整个科普系统的主线流程，没有多余的东西。我在需求文档里特别标注了"药材图片必须为实物拍摄图，不得使用手绘插图或AI生成图"，因为中药材的外观辨识本身就是科普的重要部分，很多药材长得差不多（比如白芷和独活），图片不真实会直接误导用户，这也是后面我在内容采编环节卡得最严的一条。

2. 技术选型复盘：原生开发还是uni-app，云开发还是自建后端

技术选型这个环节，我踩过的坑比较多，所以想多说几句。现在做微信小程序，摆在面前的两条岔路分别是：用原生小程序框架还是跨端框架，以及用微信云开发还是自建服务器后端。这两组决策会直接影响后续所有的开发和维护成本。

先说前端框架。我平时也写uni-app，因为一套代码可以同时发小程序、App和H5，理论上效率很高。但实际评估下来，这个中药材科普项目最终选了原生小程序开发，原因很简单：第一，项目没有多端发布的硬性需求，用户就用微信小程序，App和H5都是多余的；第二，原生小程序在真机调试、性能表现、API调用方面始终是最直接的，不需要经过一层编译转换，遇到问题可以少排查一个环节；第三，中药材科普涉及的组件并不复杂，无非是列表、搜索框、详情页、图片预览，原生的组件完全够用，不需要跨端框架带来的组件库便利。

然后是后端方案。这个决策我前后纠结了很久。一开始设想的是用Java + MySQL做一套传统的服务端，因为不少培训机构的项目都是这么教的。但冷静分析了一下项目的真实体量：内容以静态数据为主（药材信息不会频繁变动），用户量级处于早期阶段，没有复杂的并发场景，也没有交易和支付需求。这种情况下专门搞一台服务器，还要处理域名备案、HTTPS证书、接口鉴权、后台管理系统，开发和运维成本都偏高。

所以我最终选用了微信云开发作为后端方案。云开发提供的云数据库、云函数、云存储三个基础能力，刚好覆盖了这个项目的全部需求：药材的结构化信息存云数据库，药材图片存云存储，涉及搜索逻辑和内容聚合的接口用云函数封装，前端直接调用。最关键的收益是免去了服务器运维和备案的流程，开发周期至少缩短了一半。

如果你也在评估云开发的适用边界，我建议按下面这个标准来判断：

• 适合云开发：纯内容展示、信息查询、工具类小程序，数据量不大且以读为主，没有强一致性和复杂事务需求
• 不适合云开发：涉及高并发写操作、支付对账、复杂权限体系、需要和外部系统深度集成的项目

为什么我会强调这一点？因为我身边真的有人把商城系统也塞进云开发，结果遇到事务一致性问题和并发瓶颈，后期被迫迁移到自建后端，返工成本极高。选型这件事，一定要基于真实的业务体量来决策，不要图新鲜，也不要盲目跟随培训机构的项目模板。

3. 数据层设计：中药材内容库的结构化建模与数据采编

这个项目的核心资产不在代码，而在数据。中药材知识科普系统的价值，很大程度上取决于你收录的药材信息是否准确、完整、结构化程度是否足够高。所以我在开发过程中特别重视数据层设计，前后花了大半个月做数据采编和清洗。

先看云数据库的集合设计。我设计了五个核心集合：

• herbs：药材主表，存储药材的基础信息
• categories：分类表，映射传统中药分类法
• herb_relations：药材关联表，存储配伍、禁忌、相关方剂关系
• favorites：用户收藏表
• search_history：搜索历史记录表

herbs集合的字段设计是整张表的核心，我反复迭代了三版才确定下来。最终采用的结构类似这样：

{ "_id": "herb_1001", "name": "黄芪", "alias": ["北芪", "绵芪", "黄耆"], "pinyin": "huangqi", "category": "补虚药", "subcategory": "补气药", "property": { "nature": "微温", "flavor": "甘", "meridian": ["脾", "肺"] }, "efficacy": "补气升阳，固表止汗，利水消肿，生津养血", "indications": "气虚乏力，食少便溏，中气下陷，久泻脱肛，便血崩漏，表虚自汗", "usage_dosage": "9-30g，煎服", "contraindications": "表实邪盛、气滞湿阻、食积停滞、阴虚阳亢等证不宜使用", "image_urls": ["cloud://...", "cloud://..."], "related_herbs": [ {"herbId": "herb_1002", "type": "配伍", "description": "黄芪配当归，补气生血"}, {"herbId": "herb_1003", "type": "禁忌", "description": "黄芪恶防风？需注意..."} ], "source_text": "《神农本草经》", "create_time": 1612137600, "update_time": 1612137600 }

为什么要把性味归经拆成嵌套对象而不是直接用字符串？因为后期大概率要做筛选功能，比如用户点"甘味药材"或者"归肺经药材"，嵌套结构配合数据库的查询操作符可以很高效地实现这类筛选。如果直接存字符串，将来做筛选就只能在前端遍历过滤，效率低且语义不清晰。

再比如alias别名这个字段，很多人会忽略它的价值。实际上用户搜索的时候经常输入的是别名而不是正名，比如搜"山芋"指的是山药，搜"北芪"指的是黄芪。有这个字段配合搜索索引，搜索体验会好很多。

数据采编环节是整个项目里最耗时也最考验耐心的部分。我组建了一个三人小团队，分工是一人负责查阅《中国药典》和相关中医药教材，一人负责整理网络公开资料，一人负责图片素材的收集和版权筛查。所有药材信息必须经过两个来源交叉验证才能录入，特别是性味归经、用法用量、禁忌这四类关键信息，不允许只靠单一来源。

这里想特别提醒一点：药材图片的坑非常多。很多搜索引擎上搜出来的"黄芪"图片实际是其他植物的照片，或者虽然是同属植物但不是药典规定的正品基原。我做了一个硬性规定：每味药材至少需要两张图片，一张是干燥药材的实物图（饮片图），一张是植物原形态图（原植物图），两张图都必须能追溯到来源。这个标准虽然让采编工作量翻倍，但对科普类产品来说是值得的。

最终我收录了200味常见中药材的数据，这个量级对于知识科普系统来说已经足够撑起一个比较完整的内容体系，又不至于因为数据量太大导致质量控制不过来。

4. 核心功能模块实现：从分类浏览到智能搜索

内容库搭好之后，真正的开发工作开始了。前端部分我按照功能模块一个个推进，这里挑几个核心模块重点讲一下实现思路和代码细节。

4.1 首页与分类导航的实现

首页的布局相对常规：顶部搜索栏（点击跳转到搜索页而不是在本页内嵌搜索框，这样交互更简单）、轮播图（展示推荐的科普专题）、分类宫格导航（九宫格展示主要分类）、今日推荐药材列表（按更新时间随机取三条）。

分类导航的数据是在小程序启动时就加载的，因为分类表几乎不变，我把它放在了全局变量里，不需要每次打开首页都请求。只有药材列表用了云函数做分页查询，每页10条。

云函数端的分页查询代码大概长这样：

// 云函数：getHerbsByCategory const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db = cloud.database() exports.main = async (event) => { const { category, page = 1, pageSize = 10 } = event const result = await db.collection('herbs') .where({ category }) .skip((page - 1) * pageSize) .limit(pageSize) .get() return { data: result.data } }

这里有一个经验要分享：云数据库的查询默认单次最多返回20条记录，如果你直接使用前端的wx.cloud.database()来查询列表，分页做起来很绕。用云函数做一层封装，最大可以调到100条/次，对列表页来说完全够用，而且云函数里可以使用cloud.database()完整版的API，少很多限制。

4.2 搜索功能的迭代演进

搜索是一个科普系统最重要的入口，我前后做了两个版本。第一个版本只做了前缀匹配：

// 方式一：字符前缀匹配（不推荐） const db = cloud.database() const _ = db.command const result = await db.collection('herbs') .where(_.or([ { name: db.RegExp({ regexp: keyword, options: 'i' }) }, { pinyin: db.RegExp({ regexp: keyword, options: 'i' }) } ])) .limit(20) .get()

这个版本的问题很明显：用户输入"lq"想搜"黄芪"，系统匹配不到，因为黄芪的拼音是"huangqi"，只有全拼和首字母都输入完整才能搜到。另外用户输入"补气的药"这种自然语言，也没办法命中任何结果。

第二个版本我引入了云开发的数据库搜索能力。云开发目前提供了一定程度的全文搜索能力，但它依赖索引配置，而且有分词和性能的局限。综合评估后我选择了更务实的方案：在数据层增加一个_searchKeywords数组字段，把药材名、别名、拼音全拼、拼音首字母、功效关键词都放进去，搜索时只对这个字段做正则匹配。

{ "_searchKeywords": [ "黄芪", "北芪", "绵芪", "黄耆", "huangqi", "hq", "补气", "固表", "止汗" ] }

这个设计能从根源上解决搜索的匹配问题，搜索条件统一转化为"查询 _searchKeywords 中包含关键词的记录"，不管用户输入中文、全拼、首字母还是功效词，都能命中。代价是数据冗余增加了一些存储空间，但换来的搜索体验提升是值得的。

搜索历史我用了一个前端本地存储加云数据库双写的方式，本地存的目的是让搜索页可以秒开显示历史记录，云数据库存的目的是后续可以做数据分析，看看用户最关心哪类药材。

4.3 详情页的信息分层展示

药材详情页是承载科普内容的核心页面，信息量很大。为了避免用户打开页面被信息淹没，我把详情页设计成了上下分层的结构：

第一屏是药材名称、别名、高清图轮播，点击图片可以全屏预览，配合手势放大缩小查看细节纹理。小程序的原生wx.previewImage支持全屏预览，这个能力做图鉴类内容很好用，而且是免费的，不像一些第三方组件还需要额外依赖。

第二屏是核心信息卡片，用 Tab 切换的方式展示：性味归经、功效主治、用法用量、相关配伍、注意事项。性味归经用标签组展示，比如"甘""微温""归脾经""归肺经"这样的胶囊标签，视觉上比纯文字更直观。

第三屏是关联方剂和配伍说明，展示形式是卡片列表，每张卡片包含配伍的两味药材名和一句简要说明。比如"黄芪配当归，补气生血，适用于气血两虚"。

第四屏是免责声明，明确提示用户内容仅供科普参考，不能替代专业医师的诊断和建议，出现不适请及时就医。这个声明不仅是合规需要，从产品角度也是必要的信任建设。

详情页在开发时遇到一些性能上的小问题，主要是图片加载慢。中药材的实物图往往用手机拍摄的高清图，单张2-5MB很常见，在小程序里直接加载体验会很差。我的处理方案是：云存储上传图片时统一生成缩略图，用wx.cloud.getTempFileURL拿到的图片URL拼接?imageMogr2/thumbnail/!750x750r这样的处理参数让云存储实时压缩。如果不使用云存储，你也可以选择在上传图片之前用工具统一压缩一遍再传，方法不同思路是一样的，核心目标都是让首屏加载的图片体积尽量小。

下面是详情页加载的核心代码逻辑：

Page({ data: { herbDetail: null, loading: true, currentTab: 'basic' }, onLoad(options) { const herbId = options.id this.loadHerbDetail(herbId) }, async loadHerbDetail(herbId) { wx.showLoading({ title: '加载中' }) try { const res = await wx.cloud.callFunction({ name: 'getHerbDetail', data: { herbId } }) const detail = res.result.data // 云存储图片链接处理 if (detail && detail.image_urls && detail.image_urls.length > 0) { const fileRes = await wx.cloud.getTempFileURL({ fileList: detail.image_urls }) detail.image_urls = fileRes.fileList.map(item => item.tempFileURL) } this.setData({ herbDetail: detail, loading: false }) } catch (e) { console.error('获取详情失败', e) wx.showToast({ title: '加载失败', icon: 'none' }) } finally { wx.hideLoading() } }, switchTab(e) { const tab = e.currentTarget.dataset.tab this.setData({ currentTab: tab }) } })

这个逻辑要说一下设计意图：为什么通过云函数而不是前端直接查数据库？因为详情页涉及关联药材查询，比如当前药材的配伍记录里关联了另外几味药的信息，需要云函数做Promise.all批量查询，如果全部放在前端写这些数据组装逻辑，代码会非常冗长且难以维护。

4.4 收藏与浏览历史的本地存储方案

收藏和历史这两个功能我特意单独拿出来说，因为微信小程序实现这两个功能有个特别好的能力：每个用户有独立且持久化的本地存储空间wx.setStorageSync，大约支持10MB的容量，对存储简单的收藏ID列表来说完全够用。

收藏功能我采用了前端本地存储为主、云数据库为辅的双写策略。用户点击收藏时，先同步把药材ID写入本地存储数组，然后异步调用云函数写入云数据库的favorites集合。为什么要双写？因为如果只写本地，用户换设备之后收藏记录就丢了；如果只写云端，用户在弱网环境下收藏操作会因为请求超时被判定为失败，体验很差。双写策略可以在弱网环境先让用户看到收藏成功的反馈，等网络恢复后再通过云函数把收藏数据同步上去，体验上流畅很多。

浏览历史的实现更简单，每次进入详情页时把当前药材的ID和名称写入wx.setStorageSync('history', arr)，重复浏览时去重并移到数组头部，最多保留30条。由于历史数据也是纯本地，就不涉及用户隐私和合规的问题了，这对科普类工具是一个加分项。

5. 云开发环境配置和云函数的模块化拆分

云开发的工程化配置中，有几个细节容易踩坑，我单独放在一章讲。这里主要讲三个问题：环境初始化、云函数的模块化拆分、本地调试。

环境初始化方面，因为项目可能同时存在测试环境、生产环境，我在 app.js 里默认初始化了wx.cloud.init，并把env参数从配置文件读取。这样开发时用测试环境，上线发布前切换成生产环境，只需要改一个变量，不会出现调试数据和线上数据混在一起的问题。

// config/index.js module.exports = { cloudEnv: 'herb-prod-xxxx' // 上线前切换为生产环境 } // app.js const config = require('./config/index') App({ onLaunch() { if (!wx.cloud) { console.error('请使用 2.2.3 或以上的基础库以使用云能力') return } wx.cloud.init({ env: config.cloudEnv, traceUser: true }) }, globalData: { categories: [], userInfo: null } })

云函数的模块化拆分是我的一个习惯。很多云开发项目所有逻辑都堆在一个云函数里，函数的代码动辄几百上千行，后续维护极其痛苦。我的做法是按业务模块拆分：getHerbDetail、getHerbListByCategory、searchHerbs、addFavorite、removeFavorite、getFavorites，每个云函数只负责一个单一职责，代码控制在100行以内。这样做的额外收益是：云函数的冷启动时间会明显优化，因为函数包体积很小，不会加载无关的依赖代码。

本地调试方面，云函数本地调试功能已经比较成熟了，在开发者工具右键云函数目录，选择"云函数本地调试"就能用本地Node环境跑函数代码。我的团队开发时约定：涉及数据库读写和云函数逻辑的修改，一律先用本地调试跑通，再上传部署到云端，这个习惯帮我们节省了大量时间，因为云端部署上去发现报错再回来查日志，每轮至少多花5到10分钟。

6. 真机调试现场还原：请求失败、图片不加载和渲染错位

开发到测试阶段，最大的工作量不是写新功能，而是解决真机上暴露出来的各种和模拟器不一致的问题。这里我记录几个典型的排查过程，希望帮大家少走弯路。

第一个问题是模拟器一切正常，真机调试时却请求不到后端数据。打开调试器看到云函数调用返回的报错大致指向超时和权限不足。我的第一感觉是域名白名单问题，但云开发默认是免域名的，应该不是这个原因。随后我注意到报错信息里有一条environment not found的提示，排查后发现是云函数里面的环境变量没有配置。我在开发环境初始化云开发时用的是测试环境的envID，云函数里却获取不到这个环境。解决方案是在云函数的config.json里显式声明环境变量，或者在云函数代码里写死cloud.init({ env: '正式环境ID' })。这类环境不一致的问题在真机上表现得很隐蔽，因为模拟器会自动使用当前开发工具选中的环境，而真机需要通过代码明确指定。

第二个问题是详情页的药材轮播图在真机上加载不出来，但用开发者工具的预览模式看着是好的。排查后发现是wx.cloud.getTempFileURL获取的临时链接有时效性，而我之前不小心把临时链接缓存到了全局变量里，导致过期后图片无法加载。修复方式是在每次进入详情页时重新请求临时链接，不做全局缓存。另外要注意云存储的图片如果涉及访问权限设置，必须确认所有用户（包括未登录访客）都有读取权限，否则真机上会出现同一张图片有时能加载有时不能的诡异现象。

第三个问题是页面渲染错位。有个别安卓机的scroll-view在滚动时出现卡顿和底部留白，排查了一圈发现不是代码逻辑问题，而是某张药材大图的尺寸太夸张，长宽比严重失衡，导致scroll-view在做高度计算时出现异常。解决办法是对所有药材图片统一做等比裁剪：宽度750rpx，高度最多不超过1000rpx，长宽比超过一定阈值的图片在采编环节直接换图。这让我意识到内容规范对前端性能的影响远比想象中要大，当数据质量不可控的时候，前端代码写得再健壮也扛不住无规律的数据输入。

在开发者工具的Network面板和真机调试的Network面板，是两个必须都跑一遍的环节。我建议每个页面在开发完成之后都做一次"双端联测"：开发工具点击一轮，真机点击一轮，两者结果互相印证，能过滤掉90%以上的环境类Bug。

7. 发布审核与数据运营：从过审到持续优化

在功能和稳定性测试通过后，项目进入了发布审核阶段。微信小程序的审核历来是开发者最焦虑的环节，尤其是涉及医疗健康相关知识的内容，一不小心就会被驳回。中药材科普这个类目，审核最关注的几个点依次是：是否涉及医疗诊断、是否涉及处方推荐、是否有危言耸听的内容。为了避免踩雷，我的处理方法是：所有药材描述中不使用任何"治愈""根治""特效"这类绝对化表达，所有功效描述前面加上"传统中医理论认为"这一限定语，并注明信息来源。

我的体验是，医疗健康相关的科普内容如果明确标注了"仅供科普参考，不构成医疗建议"，审核通过率会提高不少。相反，如果页面里出现了任何暗示"使用某味药材可以直接缓解具体病症"的描述，基本会被打回。所以说这个领域的内容生产，边界感非常关键。如果你是个人开发者没有专业的医学背景，建议在内容上线前请中医院校的朋友帮忙审一遍，这个动作可以帮你省掉很多审核往返的成本。

小程序上线只是开始，真正持续的运营工作接踵而来。这里分享几个数字：上线第一周我在养生群里做了小范围的内测推广，日活大概在100人量级。用户收藏率最高的药材是枸杞子、黄芪、当归、人参、金银花这几位"网红"，这也符合大众认知。后台的搜索词分析里，"XXX怎么吃"和"XXX泡水喝的功效"是搜索量最大的两类长尾词，这说明用户对科普内容的需求不仅是知道药材是什么，更关心怎么用。但作为不涉及诊疗的科普产品，我只能在这些搜索词的引导上展示经过来源验证的常规用法，比如药膳食疗常用的剂量，明确标注适用人群和不适用人群，不做针对个体情况的建议。

我还在版本迭代中加入了一个"中药小课堂"内容模块，每期讲一味高频搜索的药材，从产地分布、采制方法讲到常见混淆品鉴别。比如讲黄芪那一期，我会把市面上容易混淆的"红芪"拿出来对比，这对很多想学认药的人来说非常有用。事实证明这个模块的用户停留时长是普通图文页面的三倍以上，成了留存做得最好的内容板块。

这里给想做类似科普系统的朋友一条建议：不要把产品做成一本静态的电子药典，一定要有"日更"或"周更"的栏目。App和小程序最怕的就是内容不动，内容更新频率直接决定用户的回访意愿。哪怕每周只更新一个专题，都比一次性把所有内容铺满要有效得多。

从技术上来说，这个项目的核心已经跑通了，后续如果要扩展，还有几个方向可以考虑：引入语音播报让内容可以在听书场景下使用、增加药材之间的性味冲突检测来做一个"配伍查询器"、或者以地图形式展示道地药材的产地分布。如果对中药材科普和小程序开发感兴趣，欢迎带着你的想法来交流，这一块真的是越做越有意思的领域。