我一直觉得急救常识这种东西平时没人放在心上真到用的时候恨不得回到过去多学两眼。前阵子朋友家里老人突发心梗旁边人完全不知道怎么处理白白错过了黄金四分钟这件事对我触动很大。于是我决定用自己手头的技术做一套能随时打开、快速找到正确急救方法的学习系统。技术选型我几乎没纠结——微信小程序是触达普通人成本最低的载体UniApp能让我后面想移植到App或者H5时不用重写。整套系统从立项到上线前后花了大概六周包含急救知识科普、视频教学、题库自测、学习进度记录等模块今天把整个设计过程、工程实现、踩坑总结都整理出来给正在做同类知识学习小程序的朋友一份可复用的参考。1. 产品定位与功能闭环急救学习小程序到底要做什么1.1 急救常识学习的真实痛点急救常识和普通网课不一样它的核心特征是“低频、高价值、强时效”。平时大家不会天天学但真遇到突发状况需要的是能立刻找到、看得懂、步骤清晰的内容。我调研了市面上几款急救App和小程序发现普遍存在两类问题一类是内容堆得很重像医学教材的电子版用户根本看不下去另一类是噱头很多又是社区又是社交但真到学急救知识时连心肺复苏的标准操作视频都找不到。所以我给这个项目的定位很简单做一个安静但有用的知识型小程序。用户打开后能在最短时间内找到某一类急救场景出血、烫伤、噎食、中风、心脏骤停等通过图文和短视频快速了解处置流程再用题库自测来巩固记忆。不搞复杂社交不搞积分商城先把“工具学习”的闭环做扎实。1.2 为什么是微信小程序 UniApp微信小程序作为载体几乎是必然选择。急救常识有很强的公益属性用户不会专门去应用商店下载一个App但在微信里搜索“急救常识”就能打开用完即走也方便转发给家人群、业主群。对于内容学习类产品来说小程序是最低门槛的触达方式。选择UniApp则是从工程效率和后续扩展两个维度考虑的。如果只做微信小程序原生开发完全够用但我希望这套系统后续能同步出支付宝小程序、百度小程序、H5甚至打包成App给户外俱乐部、社区物业用这时候UniApp的跨端价值就体现出来了。UniApp基于Vue语法我团队里的人会Vue就能直接上手不需要重新学一套小程序语法。而且UniApp对微信小程序的API封装得相当完整像登录、支付、分享、地图、扫码这些能力都有统一调用方式遇到跨端差异再单独写条件编译就行。我对比过Taro和原生小程序。Taro在React生态里很香但我这边团队技术栈是VueUniApp的学习成本更低原生小程序上每个端都要写一遍逻辑迭代速度跟不上。UniApp唯一的短板是遇到非常底层的性能问题调试起来比较绕但对一个内容展示型的小程序来说这个短板可以忽略。1.3 功能闭环与MVP取舍规划功能时我列了一个需求池然后用优先级砍掉不必要的功能。最终第一版保留了这几个模块首页内容流Banner推荐、分类入口、热门急救文章/视频列表。分类知识库按场景分类心肺复苏、创伤止血、烧烫伤、气道梗阻、中暑、溺水等支持搜索。视频教学与图文详情视频支持列表播放、自动暂停图文支持富文本展示包含步骤拆解和注意事项。题库自测按分类随机组卷单选多选答题后立即出结果支持错题记录。学习记录与收藏记录每个内容的学习进度方便下次接着看收藏常用内容形成“急救速查清单”。分享把单条急救知识分享给微信好友分享卡片带小标题和封面图。砍掉的功能包括社区问答、在线考试拿证书、LBS急救资源地图。不是说这些没用而是第一版不适合做。急救知识最核心的问题是内容准确性和用户信任与其铺一大堆功能不如把内容浏览和自测体验做透。等用户量起来、内容审核机制完善后再扩展AED地图、培训报名这些增值场景更稳妥。2. UniApp工程搭建与微信开发者工具跑通的完整步骤2.1 用Vite Vue3创建工程而不是HBuilderX可视化模板创建UniApp工程有两条主流路径一是直接打开HBuilderX新建项目可视化界面很友好二是用命令行创建Vite Vue3项目方便接入自己的代码仓库和CI流程。我采用的是命令行方式因为后面要团队协作用代码模板管理依赖更干净。npx degit dcloudio/uni-preset-vue#vite my-aid-app cd my-aid-app npm install npm run dev:mp-weixin执行npm run dev:mp-weixin之后项目会生成dist/dev/mp-weixin目录这就是编译出来的微信小程序代码。然后用微信开发者工具导入这个目录即可。如果你是第一次用UniApp我建议先在HBuilderX里跑通一个Hello World再看命令行工程。HBuilderX内置了UniApp的编译和运行面板点一下“运行到小程序模拟器”就能唤起微信开发者工具新手不容易迷路。但项目上到一定规模后我仍然推荐命令行版本因为CI、代码检查、依赖升级都更好控制。2.2 manifest.json里的关键配置UniApp跨端编译时很多表现差异都跟manifest.json有关。项目跑通后第一件事是打开src/manifest.json完善以下几个点小程序AppID在微信公众平台注册小程序后拿到AppID填到mp-weixin.appid。项目名称和描述会显示在微信开发者工具里后面提审也会参考提前写清楚。权限声明如果后面要使用位置接口比如找附近的AED需要在mp-weixin里声明permission字段并在__usePrivacyCheck__开启后对应弹出隐私提示。组件按需注入mp-weixin下有个lazyCodeLoading: requiredComponents建议开启能减少小程序包体冷启动更快。2.3 最容易卡住的地方运行到微信开发者工具没反应这一步是很多新手的第一道坎光我见过的就有四种原因。第一种微信开发者工具没有开启服务端口。需要在微信开发者工具的“设置 - 安全设置”里打开“服务端口”否则HBuilderX/CLI无法自动唤起甚至无法推送代码。第二种HBuilderX找不到微信开发者工具的安装路径。如果是CLI项目还好用npm run dev:mp-weixin是纯命令行编译再手动导入dist目录但用HBuilderX运行面板时它需要到HBuilderX - 运行 - 运行到小程序模拟器 - 运行设置里配置工具路径macOS经常因为路径带空格导致识别失败。第三种AppID错误或项目不是开发者。如果你用的是测试号很多真实接口会受限如果你用真AppID需要在微信公众平台把当前微信号加为项目成员和开发者。第四种编译报错但不弹窗。UniApp控制台里报了错微信开发者工具却没有任何反馈我都是先把dist/dev/mp-weixin目录删掉再重新编译能解决九成以上的“没反应”。2.4 目录结构与请求封装第一版我建议按这个结构组织代码src/ api/ # 接口请求模块按业务域拆分 components/ # 公共组件 pages/ # 页面 static/ # 静态资源 store/ # Pinia状态 utils/ # 工具函数 App.vue main.js manifest.json pages.json请求封装我统一放在utils/request.js。微信小程序的uni.request本身够用但考虑到统一错误处理、token注入、登录失效重试还是封装一层比较好。以下是一个简化版const BASE_URL https://api.example.com export function request({ url, method GET, data {} }) { return new Promise((resolve, reject) { uni.request({ url: ${BASE_URL}${url}, method, data, header: { Content-Type: application/json, Authorization: uni.getStorageSync(token) || }, success: (res) { if (res.statusCode 200 res.data.code 0) { resolve(res.data.data) } else { uni.showToast({ title: (res.data res.data.message) || 请求异常, icon: none }) reject(res) } }, fail: (err) { uni.showToast({ title: 网络异常请稍后重试, icon: none }) reject(err) } }) }) }这里要注意后端接口如果挂了小程序端不能白屏至少给用户一个toast提示并且页面要有重试按钮。急救内容的学习场景很特殊用户可能是带着紧张情绪打开的任何加载异常都必须给足反馈。3. 数据建模从急救分类到学习记录的库表设计3.1 表结构设计的核心思路急救学习系统的实体其实不复杂核心围绕“内容”和“学习行为”展开。我设计了六个核心表分类表、内容表、题目表、用户表、学习记录表、答题记录表。前端通过分类进入内容列表打开内容后记录学习进度参与题库后记录答题结果。这六个表足够支撑第一版所有功能同时避免了过度设计。内容表里我特意预留了source内容来源和audit_status审核状态字段。急救内容不是普通娱乐资讯一旦出错可能造成严重后果。所有内容必须经过专业审核才能上架这个字段在数据层面保证了“用户看不到未审核内容”。3.2 MySQL建表参考如果你使用云开发或uniCloud数据结构类似只是不用写SQL。下面给一份MySQL版本的建表语句方便理解字段含义CREATE TABLE category ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(50) NOT NULL COMMENT 分类名称, icon varchar(255) DEFAULT COMMENT 分类图标, sort int(11) DEFAULT 0 COMMENT 排序, status tinyint(1) DEFAULT 1 COMMENT 1启用 0禁用, PRIMARY KEY (id) ) COMMENT急救知识分类表; CREATE TABLE article ( id int(11) NOT NULL AUTO_INCREMENT, category_id int(11) NOT NULL COMMENT 分类ID, title varchar(200) NOT NULL COMMENT 标题, summary varchar(500) DEFAULT COMMENT 摘要, cover varchar(500) DEFAULT COMMENT 封面图, content longtext COMMENT 富文本内容, video_url varchar(500) DEFAULT COMMENT 视频地址, duration int(11) DEFAULT 0 COMMENT 视频时长秒, source varchar(100) DEFAULT COMMENT 内容来源, audit_status tinyint(1) DEFAULT 0 COMMENT 0待审核 1通过 2驳回, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category (category_id) ) COMMENT急救内容表; CREATE TABLE question ( id int(11) NOT NULL AUTO_INCREMENT, category_id int(11) NOT NULL, type tinyint(1) NOT NULL COMMENT 0单选 1多选, stem varchar(500) NOT NULL COMMENT 题干, options varchar(1000) NOT NULL COMMENT JSON格式选项, answer varchar(50) NOT NULL COMMENT 正确选项如A或AB, analysis varchar(1000) DEFAULT COMMENT 答案解析, PRIMARY KEY (id), KEY idx_question_category (category_id) ) COMMENT急救题库表; CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT, openid varchar(100) NOT NULL COMMENT 微信openid, nickname varchar(100) DEFAULT , avatar varchar(500) DEFAULT , create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) COMMENT用户表; CREATE TABLE learn_record ( id int(11) NOT NULL AUTO_INCREMENT, user_id int(11) NOT NULL, article_id int(11) NOT NULL, progress int(11) DEFAULT 0 COMMENT 学习进度百分比, finished tinyint(1) DEFAULT 0 COMMENT 是否学完, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_article (user_id, article_id) ) COMMENT学习记录表; CREATE TABLE exam_record ( id int(11) NOT NULL AUTO_INCREMENT, user_id int(11) NOT NULL, question_id int(11) NOT NULL, is_correct tinyint(1) NOT NULL, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_q (user_id, question_id) ) COMMENT答题记录表;3.3 为什么用冗余字段而不是纯标准化例如article表中冗余了category_id但没有冗余分类名称。这是因为在列表页展示时前端通过分类ID再查分类表也就一次请求没必要为了省一次关联查询把分类名冗余进去。但像learn_record表我冗余了article_id和user_id的联合索引这是为了高频查询“该用户学了哪些内容”和“该内容被多少人学过”而不是为了省事。如果后端走uniCloud云数据库建议把options这种固定结构字段直接设计成对象数组。云数据库的灵活性更高不强制规范化但对字段索引同样要提前规划好。内容表里的status字段不加索引的话内容多了以后后台分页查询会拖慢。3.4 学习进度的存储策略学习进度是整个系统的核心之一。用户看了一半退出去下次再进来要能“续看”。如果是视频内容我会每5秒上报一次进度如果是图文则根据文章总高度和当前滚动位置计算百分比。上报接口的频率不能太高防抖至少30秒一次否则用户滚动一篇长文会触发几十次接口。对于未登录用户进度先写本地缓存等登录后再合并到服务端。第一版如果不想做合并也可以直接强制用户登录后再使用学习功能但会提高使用门槛。急救学习场景里很多用户是第一次点开、觉得有用才想收藏我不建议一开始就卡登录。4. 小程序端核心学习流程的实现骨架4.1 首页自定义导航栏不只是好看小程序顶部导航栏的状态栏高度、胶囊按钮位置在不同手机上都不一样。如果要做自定义导航栏比如把搜索框放在右上角、Banner延伸到顶部必须动态计算。script setup import { ref } from vue const statusBarHeight ref(20) const navBarHeight ref(44) uni.getSystemInfo({ success: (res) { statusBarHeight.value res.statusBarHeight || 20 } }) // 胶囊按钮位置用于对齐右上角自定义按钮 const menuButton uni.getMenuButtonBoundingClientRect() if (menuButton) { navBarHeight.value menuButton.height (menuButton.top - statusBarHeight.value) * 2 } /script template view classnav-bar :style{ paddingTop: statusBarHeight px, height: navBarHeight px } view classnav-title急救常识学习/view /view /template这里有个坑uni.getMenuButtonBoundingClientRect在部分Android低版本微信里可能返回空对象做好兜底。自定义导航栏后点击状态栏或者顶部区域要能置顶滚动需要监听页面的onPageScroll自己控制返回顶部按钮的显隐。4.2 视频列表只允许一个视频播放滑出可视区自动暂停急救教学视频以短视频为主用户很可能边看边刷。如果每个video组件都是独立的很容易出现多个视频同时播放的混乱情况。我的做法是全局只保留一个当前播放ID。template view v-foritem in videos :keyitem.id classvideo-item video :idvideo_ item.id :srcitem.video_url :controlstrue :posteritem.cover playonPlay(item.id) / /view /template script setup import { ref } from vue const currentVideoId ref() function onPlay(id) { if (currentVideoId.value currentVideoId.value ! id) { // 暂停上一个视频 const ctx uni.createVideoContext(video_ currentVideoId.value) ctx.stop() } currentVideoId.value id } /script这解决了“同时播”的问题但“滑出可视区自动暂停”需要配合IntersectionObserver。建议在视频列表页的onReady里监听每一个视频节点当某个视频完全移出可视区时如果它正好是当前播放项调用ctx.pause()。微信小程序里wx.createIntersectionObserver在视频组件上有时不够灵敏尤其在iOS的swiper里嵌套video会引发全屏错位。我的解决方案是不要在swiper里直接放video来处理多视频切换改用列表页滚动 当前播放控制的方案从根源上避开全屏和手势冲突。4.3 题库自测单选和多选共用一套手写逻辑题库页面的核心是选项渲染和答案比较。选项数据我在后端存成JSON字符串前端解析成数组后渲染。单个选项的点击逻辑如下const currentQuestion ref({}) const selectedOptions ref([]) function chooseOption(optionValue) { const type currentQuestion.value.type if (type 0) { // 单选 selectedOptions.value [optionValue] } else { // 多选 const index selectedOptions.value.indexOf(optionValue) if (index -1) { selectedOptions.value.splice(index, 1) } else { selectedOptions.value.push(optionValue) } } } function submitAnswer() { const correct currentQuestion.value.answer const myAnswer selectedOptions.value.sort().join() if (myAnswer correct) { // 记录正确 } else { // 记录错误提示查看解析 } }这里要注意多选答案的比较如果正确选项是AB用户选择BA也是对的所以排序后比较另外在进入下一题前要重置selectedOptions否则上一题的选择会带到后面。每次提交后立即把答题记录传到后端这样错题本可以直接根据exam_record表里is_correct 0的记录关联出题目列表。4.4 登录、收藏、分享的实现细节登录我采用uni.login获取code传给后端换取openid然后后端签发token。这里不存微信敏感信息第一版也不需要用户授权手机号所以只需通过button open-typechooseAvatar来获取头像昵称让用户自己填。收藏按钮很常规但要注意按钮的交互反馈。用户收藏一篇急救文章后很可能后续会去“我的收藏”里查找所以收藏列表的排序我按收藏时间倒序并且卡片上要保留分类标签方便快速定位。分享功能用自定义onShareAppMessage返回标题、路径和图片。需要特别注意的是如果你在mixins或全局对象里定义了onShareAppMessage页面里再定义自己的分享函数时全局版本会被覆盖。这是第5节会展开说的一个坑。5. 避坑实录我在急救学习小程序里踩过的九个坑5.1 分享方法被全局覆盖导致分享卡片不带参数我很想全局统一定义分享标题所以在一个公共mixins里写了onShareAppMessage统一返回“急救常识学习”的标题和封面。结果发现所有页面分享出去都变成一样了从首页分享“心肺复苏指南”这个页面好友打开后看到的还是首页。原因是微信小程序生命周期里页面级的onShareAppMessage会覆盖默认配置但如果页面没有定义它全局对象或mixins里的定义是生效的。问题出在我们的页面确实定义了分享函数只是忘了返回自定义参数。解决办法在页面级分享函数里动态读取当前页面数据。onShareAppMessage() { const article routeData.value return { title: article.title || 急救常识学习, path: /pages/article/detail?id${article.id}, imageUrl: article.cover } }如果你要保留全局默认值可以在mixins里先返回一份默认对象然后在页面级函数中基于它做浅拷贝再覆盖字段。5.2 视频滑出可视区后仍然在播放这个坑和4.2节关联。一开始我只实现了“点击当前视频时暂停上一个”但用户快速上滑后被滑出去的那个视频继续发声体验非常糟。我用createIntersectionObserver监听当前播放项当它的intersectionRatio小于0.2时自动暂停。这里有一个优化不要在每帧回调里判断只在onScroll结束后做一次检查或者用500ms防抖。否则列表页滚动的性能会明显下降尤其Android低端机器上会卡。const observer uni.createIntersectionObserver(this) observer.relativeToViewport({ top: 0, bottom: 0 }) observer.observe(.video-playing, (res) { if (res.intersectionRatio 0.2 currentVideoId.value) { const ctx uni.createVideoContext(video_ currentVideoId.value) ctx.pause() } })5.3 iOS软键盘把搜索框顶到看不见首页右上角有搜索框用户点击后如果软键盘弹起搜索框容易被顶出可视区域。这个鬼问题在iOS Safari和微信小程序里都出现过。常规做法是设置input :adjust-positionfalse /然后在聚焦事件里手动把页面滚到合适位置。我这里推荐一个更稳的方案搜索框所在的头部区域改为自定义导航栏输入框固定在导航栏中当键盘弹起时通过uni.pageScrollTo带动整个导航栏滚动到可视区。或者直接改成跳转到独立的搜索页面搜索页面顶部就是输入框天然不会被遮挡。第一版要赶工期我选了后者不仅解决了遮挡还让搜索页可以做搜索历史和热门推荐。5.4 Popup弹窗背后的内容跟着滚动内容详情页里我加了一个“查看解析”的底部弹出层结果发现弹层打开后手指在背景区域滑动详情页的正文还在滚动。这会让用户误以为弹层不生效体验很糟糕。解决办法是在弹层遮罩上添加catchtouchmovenoop阻止冒泡或在页面根节点上控制page的overflow。UniApp跨端时H5端可以用touchmove.stop.prevent小程序端用catchtouchmove更可靠。还要注意如果弹层里有滚动的富文本内容不能简单禁用所有touchmove需要在弹层内部单独设置滚动容器。5.5 扫码结果有时是一串数字这个项目里我用uni.scanCode做了一个后台小功能扫描内容二维码跳转到对应急救知识页。实测中发现部分二维码识别出来的结果是纯数字而不是链接路径。问题通常出在二维码类型上有些后台生成的临时小程序码扫描结果返回的是小程序码的字符串标识不是path。这时需要区分普通链接二维码扫描结果是完整的https://xxx用web-view或正则提取路径。小程序码uni.scanCode的result可能是一串原始字符串真实跳转要依赖path字段。我的解决方法是如果scanType包含QR_CODE但result不是合法URL就尝试通过后端解析映射表根据码值查内容ID。这个功能派生于急救知识站点的线下物料投放后面可以把二维码里的内容ID直接做成短链接形式省去映射表。5.6 tabbar页面管理员才显示普通用户隐藏急救系统后台要管理内容所以我有一个“管理入口”在tabbar上但普通用户不该看到。UniApp的tabbar是全局配置无法直接在pages.json里按用户隐藏。我的做法是启动时根据用户角色调用uni.setTabBarItem修改某一项的visible。不过要注意uni.setTabBarItem对visible的支持要看基础库版本低版本微信下无效。更稳的办法是tabbar只保留4个默认项管理入口不放tabbar而是放在“我的”页面里的一个普通按钮普通用户看不到这个按钮即可。确实有管理刚需的话再做独立的管理端小程序开发量也不大。5.7 HBuilderX运行到微信开发者工具“没反应”的真凶这在第2节简单提过但值得单独拿出来说。如果你的CLI工程运行npm run dev:mp-weixin后微信开发者工具没有自动打开大概率不是编译问题而是微信开发者工具没有开启“服务端口”。打开“设置 - 安全 - 服务端口”保证开关是开着的。如果用HBuilderX运行面板还需要在“运行设置”里指定微信开发者工具的安装路径。另外一个隐蔽的坑如果微信开发者工具已经打开并加载了旧的dist目录新编译结果可能因为文件监听冲突而没刷新。保险操作是先关闭工具里的项目再重新导入目录。我后来直接用CLI的--watch模式配合微信开发者工具自身的热重载稳定很多。5.8 用户拒绝隐私授权后怎么优雅退出小程序会弹出隐私协议弹窗用户如果明确拒绝不能让用户卡在空白页。微信小程序本身没有uni.exit但可以引导用户通过右上角关闭小程序。如果你打包成AppUniApp里可以用plus.runtime.quit()退出应用。这里的边界是不强迫用户接受授权而是说明“部分功能受限”。我们的急救学习内容绝大部分不需要敏感权限只有使用地图定位找AED时才需要。所以隐私弹窗允许拒绝拒绝后只是不展示附近AED不影响学习。这个策略既合规又不会流失用户。5.9 上架安卓应用市场前的隐私弹窗适配如果你把UniApp项目打包成App发布到安卓应用市场隐私弹窗的展示时机和文案都有严格要求。很多应用市场审核会检查App首次启动时是否在采集任何信息之前就弹出隐私政策弹窗。UniApp在App端默认有隐私弹窗示例但和个人信息保护法的要求接轨时仍建议自己重写弹窗在App.vue的onLaunch里先调用uni.getPrivacySetting判断状态再决定是否展示自定义弹窗。这里我不展开全部代码但要提醒不要为了过审随便拼一个隐私弹窗一定要把“收集了什么信息、用于什么目的、存储多久”写清楚。急救学习系统本身不碰健康数据如果未来用户上传体检报告等医疗相关信息合规要求会更高。6. 医疗内容的合规运营这部分比技术更难6.1 内容来源与专业审核急救常识的准确性是项目的生命线。技术上线很快内容却需要持续投入。我在后台内容表里设计了source字段要求每篇文章都要注明来源例如国家权威机构发布的急救指南红十字会/医院医生的公开科普内容经过授权转载的医学专业媒体内容所有内容在audit_status 1之前都不会被前端查询到。这个审核流程最好有专业医生参与。我在项目里找了两位三甲医院的急诊科朋友帮忙做终审即使他们只能抽空看重点内容也比没有强太多。另外视频内容涉及真人演示心肺复苏、海姆立克等操作必须确保演示动作是标准的。我宁可减少视频数量也不放任何有争议的操作演示。6.2 小程序类目选择和资质微信小程序对医疗健康类目审核非常严格。急救常识本身偏科普教育可以选择“教育-教育信息服务”或“医疗-健康科普”具体以微信公众平台最新类目要求为准。如果涉及在线问诊、用药建议资质要求会立刻上升好几个台阶。我的建议是不要以“在线诊疗”为卖点。在简介里写明“本小程序提供急救科普知识不构成医疗建议”。页面内所有涉及“拨打120”的引导文案要克制强调“立即求助专业急救人员”。6.3 免责声明不是摆设免责声明我放在两个地方首次进入的隐私弹窗里有一条“内容仅供学习参考不能代替执业医师面诊”内容详情页底部固定一行“遇到紧急情况请第一时间拨打120”。很多开发者觉得免责声明只是法律工具但在急救场景里它也是在帮用户建立正确的急救意识——用户在紧张状态下容易照本宣科必须提醒他们求助专业人士。我还做了一个小功能每篇文章末尾都放一个长按拨打120的按钮。不是让用户依赖小程序求救而是希望在需要时能最快拨出电话。技术上也简单uni.makePhoneCall({ phoneNumber: 120 })但要注意在调起前弹窗确认防止误触。6.4 内容更新节奏急救知识不是一成不变的比如心肺复苏按压深度会根据最新指南调整。我给自己定的内容更新节奏是每季度全面检查一次核心指南类内容平时发现可疑内容立刻下线。后台管理端做了一个“内容过期预警”字段根据内容类型设置提醒周期比如“心肺复苏指南”每12个月提醒复核一次。顺便说句掏心窝的话做这类项目不要为了追求流量去编一些“急救偏方”比如烫伤抹牙膏、流鼻血仰头这些全是错误且可能造成二次伤害的内容。用户的一个转发动作可能影响很多人的急救行为内容上的红线比任何技术优化都重要。7. 后续扩展方向与我的真实体会系统上线跑了一段时间数据比预期好。用户收藏最多的是“海姆立克急救法”和“心肺复苏”说明大家不是不关心急救而是缺少一个能放心看、看得懂的内容入口。这让我意识到技术从来不是急救常识普及的瓶颈信任才是。后续我这边的扩展计划有三个方向场景化模拟练习用文字逐步模拟突发场景让用户自己做判断系统给反馈比单纯刷题记忆效果更好。AED网点地图对接开放地图数据帮用户在紧急时刻快速找到附近除颤仪这需要额外的数据审核和维护。与本地急救培训机构合作在课程学习完毕后展示培训报名入口让有意愿的用户接受线下实操训练。最后再分享一个小技巧如果你也在做这类知识型小程序请把所有“学习进度”和“收藏”的用户数据都做云端同步不要只用本地缓存。我见过不少同类小程序用户换手机后学习记录全没了信任感瞬间清零。哪怕后端复杂度高一点也值得一开始就做对。急救常识学习的核心不是“学完拿证”而是让普通人在需要时能想起来、敢上手。希望这篇基于微信小程序和UniApp的复盘能帮正要走同一条路的朋友减少几个晚上的折腾。
基于UniApp的急救知识学习微信小程序开发实战
我一直觉得急救常识这种东西平时没人放在心上真到用的时候恨不得回到过去多学两眼。前阵子朋友家里老人突发心梗旁边人完全不知道怎么处理白白错过了黄金四分钟这件事对我触动很大。于是我决定用自己手头的技术做一套能随时打开、快速找到正确急救方法的学习系统。技术选型我几乎没纠结——微信小程序是触达普通人成本最低的载体UniApp能让我后面想移植到App或者H5时不用重写。整套系统从立项到上线前后花了大概六周包含急救知识科普、视频教学、题库自测、学习进度记录等模块今天把整个设计过程、工程实现、踩坑总结都整理出来给正在做同类知识学习小程序的朋友一份可复用的参考。1. 产品定位与功能闭环急救学习小程序到底要做什么1.1 急救常识学习的真实痛点急救常识和普通网课不一样它的核心特征是“低频、高价值、强时效”。平时大家不会天天学但真遇到突发状况需要的是能立刻找到、看得懂、步骤清晰的内容。我调研了市面上几款急救App和小程序发现普遍存在两类问题一类是内容堆得很重像医学教材的电子版用户根本看不下去另一类是噱头很多又是社区又是社交但真到学急救知识时连心肺复苏的标准操作视频都找不到。所以我给这个项目的定位很简单做一个安静但有用的知识型小程序。用户打开后能在最短时间内找到某一类急救场景出血、烫伤、噎食、中风、心脏骤停等通过图文和短视频快速了解处置流程再用题库自测来巩固记忆。不搞复杂社交不搞积分商城先把“工具学习”的闭环做扎实。1.2 为什么是微信小程序 UniApp微信小程序作为载体几乎是必然选择。急救常识有很强的公益属性用户不会专门去应用商店下载一个App但在微信里搜索“急救常识”就能打开用完即走也方便转发给家人群、业主群。对于内容学习类产品来说小程序是最低门槛的触达方式。选择UniApp则是从工程效率和后续扩展两个维度考虑的。如果只做微信小程序原生开发完全够用但我希望这套系统后续能同步出支付宝小程序、百度小程序、H5甚至打包成App给户外俱乐部、社区物业用这时候UniApp的跨端价值就体现出来了。UniApp基于Vue语法我团队里的人会Vue就能直接上手不需要重新学一套小程序语法。而且UniApp对微信小程序的API封装得相当完整像登录、支付、分享、地图、扫码这些能力都有统一调用方式遇到跨端差异再单独写条件编译就行。我对比过Taro和原生小程序。Taro在React生态里很香但我这边团队技术栈是VueUniApp的学习成本更低原生小程序上每个端都要写一遍逻辑迭代速度跟不上。UniApp唯一的短板是遇到非常底层的性能问题调试起来比较绕但对一个内容展示型的小程序来说这个短板可以忽略。1.3 功能闭环与MVP取舍规划功能时我列了一个需求池然后用优先级砍掉不必要的功能。最终第一版保留了这几个模块首页内容流Banner推荐、分类入口、热门急救文章/视频列表。分类知识库按场景分类心肺复苏、创伤止血、烧烫伤、气道梗阻、中暑、溺水等支持搜索。视频教学与图文详情视频支持列表播放、自动暂停图文支持富文本展示包含步骤拆解和注意事项。题库自测按分类随机组卷单选多选答题后立即出结果支持错题记录。学习记录与收藏记录每个内容的学习进度方便下次接着看收藏常用内容形成“急救速查清单”。分享把单条急救知识分享给微信好友分享卡片带小标题和封面图。砍掉的功能包括社区问答、在线考试拿证书、LBS急救资源地图。不是说这些没用而是第一版不适合做。急救知识最核心的问题是内容准确性和用户信任与其铺一大堆功能不如把内容浏览和自测体验做透。等用户量起来、内容审核机制完善后再扩展AED地图、培训报名这些增值场景更稳妥。2. UniApp工程搭建与微信开发者工具跑通的完整步骤2.1 用Vite Vue3创建工程而不是HBuilderX可视化模板创建UniApp工程有两条主流路径一是直接打开HBuilderX新建项目可视化界面很友好二是用命令行创建Vite Vue3项目方便接入自己的代码仓库和CI流程。我采用的是命令行方式因为后面要团队协作用代码模板管理依赖更干净。npx degit dcloudio/uni-preset-vue#vite my-aid-app cd my-aid-app npm install npm run dev:mp-weixin执行npm run dev:mp-weixin之后项目会生成dist/dev/mp-weixin目录这就是编译出来的微信小程序代码。然后用微信开发者工具导入这个目录即可。如果你是第一次用UniApp我建议先在HBuilderX里跑通一个Hello World再看命令行工程。HBuilderX内置了UniApp的编译和运行面板点一下“运行到小程序模拟器”就能唤起微信开发者工具新手不容易迷路。但项目上到一定规模后我仍然推荐命令行版本因为CI、代码检查、依赖升级都更好控制。2.2 manifest.json里的关键配置UniApp跨端编译时很多表现差异都跟manifest.json有关。项目跑通后第一件事是打开src/manifest.json完善以下几个点小程序AppID在微信公众平台注册小程序后拿到AppID填到mp-weixin.appid。项目名称和描述会显示在微信开发者工具里后面提审也会参考提前写清楚。权限声明如果后面要使用位置接口比如找附近的AED需要在mp-weixin里声明permission字段并在__usePrivacyCheck__开启后对应弹出隐私提示。组件按需注入mp-weixin下有个lazyCodeLoading: requiredComponents建议开启能减少小程序包体冷启动更快。2.3 最容易卡住的地方运行到微信开发者工具没反应这一步是很多新手的第一道坎光我见过的就有四种原因。第一种微信开发者工具没有开启服务端口。需要在微信开发者工具的“设置 - 安全设置”里打开“服务端口”否则HBuilderX/CLI无法自动唤起甚至无法推送代码。第二种HBuilderX找不到微信开发者工具的安装路径。如果是CLI项目还好用npm run dev:mp-weixin是纯命令行编译再手动导入dist目录但用HBuilderX运行面板时它需要到HBuilderX - 运行 - 运行到小程序模拟器 - 运行设置里配置工具路径macOS经常因为路径带空格导致识别失败。第三种AppID错误或项目不是开发者。如果你用的是测试号很多真实接口会受限如果你用真AppID需要在微信公众平台把当前微信号加为项目成员和开发者。第四种编译报错但不弹窗。UniApp控制台里报了错微信开发者工具却没有任何反馈我都是先把dist/dev/mp-weixin目录删掉再重新编译能解决九成以上的“没反应”。2.4 目录结构与请求封装第一版我建议按这个结构组织代码src/ api/ # 接口请求模块按业务域拆分 components/ # 公共组件 pages/ # 页面 static/ # 静态资源 store/ # Pinia状态 utils/ # 工具函数 App.vue main.js manifest.json pages.json请求封装我统一放在utils/request.js。微信小程序的uni.request本身够用但考虑到统一错误处理、token注入、登录失效重试还是封装一层比较好。以下是一个简化版const BASE_URL https://api.example.com export function request({ url, method GET, data {} }) { return new Promise((resolve, reject) { uni.request({ url: ${BASE_URL}${url}, method, data, header: { Content-Type: application/json, Authorization: uni.getStorageSync(token) || }, success: (res) { if (res.statusCode 200 res.data.code 0) { resolve(res.data.data) } else { uni.showToast({ title: (res.data res.data.message) || 请求异常, icon: none }) reject(res) } }, fail: (err) { uni.showToast({ title: 网络异常请稍后重试, icon: none }) reject(err) } }) }) }这里要注意后端接口如果挂了小程序端不能白屏至少给用户一个toast提示并且页面要有重试按钮。急救内容的学习场景很特殊用户可能是带着紧张情绪打开的任何加载异常都必须给足反馈。3. 数据建模从急救分类到学习记录的库表设计3.1 表结构设计的核心思路急救学习系统的实体其实不复杂核心围绕“内容”和“学习行为”展开。我设计了六个核心表分类表、内容表、题目表、用户表、学习记录表、答题记录表。前端通过分类进入内容列表打开内容后记录学习进度参与题库后记录答题结果。这六个表足够支撑第一版所有功能同时避免了过度设计。内容表里我特意预留了source内容来源和audit_status审核状态字段。急救内容不是普通娱乐资讯一旦出错可能造成严重后果。所有内容必须经过专业审核才能上架这个字段在数据层面保证了“用户看不到未审核内容”。3.2 MySQL建表参考如果你使用云开发或uniCloud数据结构类似只是不用写SQL。下面给一份MySQL版本的建表语句方便理解字段含义CREATE TABLE category ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(50) NOT NULL COMMENT 分类名称, icon varchar(255) DEFAULT COMMENT 分类图标, sort int(11) DEFAULT 0 COMMENT 排序, status tinyint(1) DEFAULT 1 COMMENT 1启用 0禁用, PRIMARY KEY (id) ) COMMENT急救知识分类表; CREATE TABLE article ( id int(11) NOT NULL AUTO_INCREMENT, category_id int(11) NOT NULL COMMENT 分类ID, title varchar(200) NOT NULL COMMENT 标题, summary varchar(500) DEFAULT COMMENT 摘要, cover varchar(500) DEFAULT COMMENT 封面图, content longtext COMMENT 富文本内容, video_url varchar(500) DEFAULT COMMENT 视频地址, duration int(11) DEFAULT 0 COMMENT 视频时长秒, source varchar(100) DEFAULT COMMENT 内容来源, audit_status tinyint(1) DEFAULT 0 COMMENT 0待审核 1通过 2驳回, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category (category_id) ) COMMENT急救内容表; CREATE TABLE question ( id int(11) NOT NULL AUTO_INCREMENT, category_id int(11) NOT NULL, type tinyint(1) NOT NULL COMMENT 0单选 1多选, stem varchar(500) NOT NULL COMMENT 题干, options varchar(1000) NOT NULL COMMENT JSON格式选项, answer varchar(50) NOT NULL COMMENT 正确选项如A或AB, analysis varchar(1000) DEFAULT COMMENT 答案解析, PRIMARY KEY (id), KEY idx_question_category (category_id) ) COMMENT急救题库表; CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT, openid varchar(100) NOT NULL COMMENT 微信openid, nickname varchar(100) DEFAULT , avatar varchar(500) DEFAULT , create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) COMMENT用户表; CREATE TABLE learn_record ( id int(11) NOT NULL AUTO_INCREMENT, user_id int(11) NOT NULL, article_id int(11) NOT NULL, progress int(11) DEFAULT 0 COMMENT 学习进度百分比, finished tinyint(1) DEFAULT 0 COMMENT 是否学完, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_article (user_id, article_id) ) COMMENT学习记录表; CREATE TABLE exam_record ( id int(11) NOT NULL AUTO_INCREMENT, user_id int(11) NOT NULL, question_id int(11) NOT NULL, is_correct tinyint(1) NOT NULL, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_q (user_id, question_id) ) COMMENT答题记录表;3.3 为什么用冗余字段而不是纯标准化例如article表中冗余了category_id但没有冗余分类名称。这是因为在列表页展示时前端通过分类ID再查分类表也就一次请求没必要为了省一次关联查询把分类名冗余进去。但像learn_record表我冗余了article_id和user_id的联合索引这是为了高频查询“该用户学了哪些内容”和“该内容被多少人学过”而不是为了省事。如果后端走uniCloud云数据库建议把options这种固定结构字段直接设计成对象数组。云数据库的灵活性更高不强制规范化但对字段索引同样要提前规划好。内容表里的status字段不加索引的话内容多了以后后台分页查询会拖慢。3.4 学习进度的存储策略学习进度是整个系统的核心之一。用户看了一半退出去下次再进来要能“续看”。如果是视频内容我会每5秒上报一次进度如果是图文则根据文章总高度和当前滚动位置计算百分比。上报接口的频率不能太高防抖至少30秒一次否则用户滚动一篇长文会触发几十次接口。对于未登录用户进度先写本地缓存等登录后再合并到服务端。第一版如果不想做合并也可以直接强制用户登录后再使用学习功能但会提高使用门槛。急救学习场景里很多用户是第一次点开、觉得有用才想收藏我不建议一开始就卡登录。4. 小程序端核心学习流程的实现骨架4.1 首页自定义导航栏不只是好看小程序顶部导航栏的状态栏高度、胶囊按钮位置在不同手机上都不一样。如果要做自定义导航栏比如把搜索框放在右上角、Banner延伸到顶部必须动态计算。script setup import { ref } from vue const statusBarHeight ref(20) const navBarHeight ref(44) uni.getSystemInfo({ success: (res) { statusBarHeight.value res.statusBarHeight || 20 } }) // 胶囊按钮位置用于对齐右上角自定义按钮 const menuButton uni.getMenuButtonBoundingClientRect() if (menuButton) { navBarHeight.value menuButton.height (menuButton.top - statusBarHeight.value) * 2 } /script template view classnav-bar :style{ paddingTop: statusBarHeight px, height: navBarHeight px } view classnav-title急救常识学习/view /view /template这里有个坑uni.getMenuButtonBoundingClientRect在部分Android低版本微信里可能返回空对象做好兜底。自定义导航栏后点击状态栏或者顶部区域要能置顶滚动需要监听页面的onPageScroll自己控制返回顶部按钮的显隐。4.2 视频列表只允许一个视频播放滑出可视区自动暂停急救教学视频以短视频为主用户很可能边看边刷。如果每个video组件都是独立的很容易出现多个视频同时播放的混乱情况。我的做法是全局只保留一个当前播放ID。template view v-foritem in videos :keyitem.id classvideo-item video :idvideo_ item.id :srcitem.video_url :controlstrue :posteritem.cover playonPlay(item.id) / /view /template script setup import { ref } from vue const currentVideoId ref() function onPlay(id) { if (currentVideoId.value currentVideoId.value ! id) { // 暂停上一个视频 const ctx uni.createVideoContext(video_ currentVideoId.value) ctx.stop() } currentVideoId.value id } /script这解决了“同时播”的问题但“滑出可视区自动暂停”需要配合IntersectionObserver。建议在视频列表页的onReady里监听每一个视频节点当某个视频完全移出可视区时如果它正好是当前播放项调用ctx.pause()。微信小程序里wx.createIntersectionObserver在视频组件上有时不够灵敏尤其在iOS的swiper里嵌套video会引发全屏错位。我的解决方案是不要在swiper里直接放video来处理多视频切换改用列表页滚动 当前播放控制的方案从根源上避开全屏和手势冲突。4.3 题库自测单选和多选共用一套手写逻辑题库页面的核心是选项渲染和答案比较。选项数据我在后端存成JSON字符串前端解析成数组后渲染。单个选项的点击逻辑如下const currentQuestion ref({}) const selectedOptions ref([]) function chooseOption(optionValue) { const type currentQuestion.value.type if (type 0) { // 单选 selectedOptions.value [optionValue] } else { // 多选 const index selectedOptions.value.indexOf(optionValue) if (index -1) { selectedOptions.value.splice(index, 1) } else { selectedOptions.value.push(optionValue) } } } function submitAnswer() { const correct currentQuestion.value.answer const myAnswer selectedOptions.value.sort().join() if (myAnswer correct) { // 记录正确 } else { // 记录错误提示查看解析 } }这里要注意多选答案的比较如果正确选项是AB用户选择BA也是对的所以排序后比较另外在进入下一题前要重置selectedOptions否则上一题的选择会带到后面。每次提交后立即把答题记录传到后端这样错题本可以直接根据exam_record表里is_correct 0的记录关联出题目列表。4.4 登录、收藏、分享的实现细节登录我采用uni.login获取code传给后端换取openid然后后端签发token。这里不存微信敏感信息第一版也不需要用户授权手机号所以只需通过button open-typechooseAvatar来获取头像昵称让用户自己填。收藏按钮很常规但要注意按钮的交互反馈。用户收藏一篇急救文章后很可能后续会去“我的收藏”里查找所以收藏列表的排序我按收藏时间倒序并且卡片上要保留分类标签方便快速定位。分享功能用自定义onShareAppMessage返回标题、路径和图片。需要特别注意的是如果你在mixins或全局对象里定义了onShareAppMessage页面里再定义自己的分享函数时全局版本会被覆盖。这是第5节会展开说的一个坑。5. 避坑实录我在急救学习小程序里踩过的九个坑5.1 分享方法被全局覆盖导致分享卡片不带参数我很想全局统一定义分享标题所以在一个公共mixins里写了onShareAppMessage统一返回“急救常识学习”的标题和封面。结果发现所有页面分享出去都变成一样了从首页分享“心肺复苏指南”这个页面好友打开后看到的还是首页。原因是微信小程序生命周期里页面级的onShareAppMessage会覆盖默认配置但如果页面没有定义它全局对象或mixins里的定义是生效的。问题出在我们的页面确实定义了分享函数只是忘了返回自定义参数。解决办法在页面级分享函数里动态读取当前页面数据。onShareAppMessage() { const article routeData.value return { title: article.title || 急救常识学习, path: /pages/article/detail?id${article.id}, imageUrl: article.cover } }如果你要保留全局默认值可以在mixins里先返回一份默认对象然后在页面级函数中基于它做浅拷贝再覆盖字段。5.2 视频滑出可视区后仍然在播放这个坑和4.2节关联。一开始我只实现了“点击当前视频时暂停上一个”但用户快速上滑后被滑出去的那个视频继续发声体验非常糟。我用createIntersectionObserver监听当前播放项当它的intersectionRatio小于0.2时自动暂停。这里有一个优化不要在每帧回调里判断只在onScroll结束后做一次检查或者用500ms防抖。否则列表页滚动的性能会明显下降尤其Android低端机器上会卡。const observer uni.createIntersectionObserver(this) observer.relativeToViewport({ top: 0, bottom: 0 }) observer.observe(.video-playing, (res) { if (res.intersectionRatio 0.2 currentVideoId.value) { const ctx uni.createVideoContext(video_ currentVideoId.value) ctx.pause() } })5.3 iOS软键盘把搜索框顶到看不见首页右上角有搜索框用户点击后如果软键盘弹起搜索框容易被顶出可视区域。这个鬼问题在iOS Safari和微信小程序里都出现过。常规做法是设置input :adjust-positionfalse /然后在聚焦事件里手动把页面滚到合适位置。我这里推荐一个更稳的方案搜索框所在的头部区域改为自定义导航栏输入框固定在导航栏中当键盘弹起时通过uni.pageScrollTo带动整个导航栏滚动到可视区。或者直接改成跳转到独立的搜索页面搜索页面顶部就是输入框天然不会被遮挡。第一版要赶工期我选了后者不仅解决了遮挡还让搜索页可以做搜索历史和热门推荐。5.4 Popup弹窗背后的内容跟着滚动内容详情页里我加了一个“查看解析”的底部弹出层结果发现弹层打开后手指在背景区域滑动详情页的正文还在滚动。这会让用户误以为弹层不生效体验很糟糕。解决办法是在弹层遮罩上添加catchtouchmovenoop阻止冒泡或在页面根节点上控制page的overflow。UniApp跨端时H5端可以用touchmove.stop.prevent小程序端用catchtouchmove更可靠。还要注意如果弹层里有滚动的富文本内容不能简单禁用所有touchmove需要在弹层内部单独设置滚动容器。5.5 扫码结果有时是一串数字这个项目里我用uni.scanCode做了一个后台小功能扫描内容二维码跳转到对应急救知识页。实测中发现部分二维码识别出来的结果是纯数字而不是链接路径。问题通常出在二维码类型上有些后台生成的临时小程序码扫描结果返回的是小程序码的字符串标识不是path。这时需要区分普通链接二维码扫描结果是完整的https://xxx用web-view或正则提取路径。小程序码uni.scanCode的result可能是一串原始字符串真实跳转要依赖path字段。我的解决方法是如果scanType包含QR_CODE但result不是合法URL就尝试通过后端解析映射表根据码值查内容ID。这个功能派生于急救知识站点的线下物料投放后面可以把二维码里的内容ID直接做成短链接形式省去映射表。5.6 tabbar页面管理员才显示普通用户隐藏急救系统后台要管理内容所以我有一个“管理入口”在tabbar上但普通用户不该看到。UniApp的tabbar是全局配置无法直接在pages.json里按用户隐藏。我的做法是启动时根据用户角色调用uni.setTabBarItem修改某一项的visible。不过要注意uni.setTabBarItem对visible的支持要看基础库版本低版本微信下无效。更稳的办法是tabbar只保留4个默认项管理入口不放tabbar而是放在“我的”页面里的一个普通按钮普通用户看不到这个按钮即可。确实有管理刚需的话再做独立的管理端小程序开发量也不大。5.7 HBuilderX运行到微信开发者工具“没反应”的真凶这在第2节简单提过但值得单独拿出来说。如果你的CLI工程运行npm run dev:mp-weixin后微信开发者工具没有自动打开大概率不是编译问题而是微信开发者工具没有开启“服务端口”。打开“设置 - 安全 - 服务端口”保证开关是开着的。如果用HBuilderX运行面板还需要在“运行设置”里指定微信开发者工具的安装路径。另外一个隐蔽的坑如果微信开发者工具已经打开并加载了旧的dist目录新编译结果可能因为文件监听冲突而没刷新。保险操作是先关闭工具里的项目再重新导入目录。我后来直接用CLI的--watch模式配合微信开发者工具自身的热重载稳定很多。5.8 用户拒绝隐私授权后怎么优雅退出小程序会弹出隐私协议弹窗用户如果明确拒绝不能让用户卡在空白页。微信小程序本身没有uni.exit但可以引导用户通过右上角关闭小程序。如果你打包成AppUniApp里可以用plus.runtime.quit()退出应用。这里的边界是不强迫用户接受授权而是说明“部分功能受限”。我们的急救学习内容绝大部分不需要敏感权限只有使用地图定位找AED时才需要。所以隐私弹窗允许拒绝拒绝后只是不展示附近AED不影响学习。这个策略既合规又不会流失用户。5.9 上架安卓应用市场前的隐私弹窗适配如果你把UniApp项目打包成App发布到安卓应用市场隐私弹窗的展示时机和文案都有严格要求。很多应用市场审核会检查App首次启动时是否在采集任何信息之前就弹出隐私政策弹窗。UniApp在App端默认有隐私弹窗示例但和个人信息保护法的要求接轨时仍建议自己重写弹窗在App.vue的onLaunch里先调用uni.getPrivacySetting判断状态再决定是否展示自定义弹窗。这里我不展开全部代码但要提醒不要为了过审随便拼一个隐私弹窗一定要把“收集了什么信息、用于什么目的、存储多久”写清楚。急救学习系统本身不碰健康数据如果未来用户上传体检报告等医疗相关信息合规要求会更高。6. 医疗内容的合规运营这部分比技术更难6.1 内容来源与专业审核急救常识的准确性是项目的生命线。技术上线很快内容却需要持续投入。我在后台内容表里设计了source字段要求每篇文章都要注明来源例如国家权威机构发布的急救指南红十字会/医院医生的公开科普内容经过授权转载的医学专业媒体内容所有内容在audit_status 1之前都不会被前端查询到。这个审核流程最好有专业医生参与。我在项目里找了两位三甲医院的急诊科朋友帮忙做终审即使他们只能抽空看重点内容也比没有强太多。另外视频内容涉及真人演示心肺复苏、海姆立克等操作必须确保演示动作是标准的。我宁可减少视频数量也不放任何有争议的操作演示。6.2 小程序类目选择和资质微信小程序对医疗健康类目审核非常严格。急救常识本身偏科普教育可以选择“教育-教育信息服务”或“医疗-健康科普”具体以微信公众平台最新类目要求为准。如果涉及在线问诊、用药建议资质要求会立刻上升好几个台阶。我的建议是不要以“在线诊疗”为卖点。在简介里写明“本小程序提供急救科普知识不构成医疗建议”。页面内所有涉及“拨打120”的引导文案要克制强调“立即求助专业急救人员”。6.3 免责声明不是摆设免责声明我放在两个地方首次进入的隐私弹窗里有一条“内容仅供学习参考不能代替执业医师面诊”内容详情页底部固定一行“遇到紧急情况请第一时间拨打120”。很多开发者觉得免责声明只是法律工具但在急救场景里它也是在帮用户建立正确的急救意识——用户在紧张状态下容易照本宣科必须提醒他们求助专业人士。我还做了一个小功能每篇文章末尾都放一个长按拨打120的按钮。不是让用户依赖小程序求救而是希望在需要时能最快拨出电话。技术上也简单uni.makePhoneCall({ phoneNumber: 120 })但要注意在调起前弹窗确认防止误触。6.4 内容更新节奏急救知识不是一成不变的比如心肺复苏按压深度会根据最新指南调整。我给自己定的内容更新节奏是每季度全面检查一次核心指南类内容平时发现可疑内容立刻下线。后台管理端做了一个“内容过期预警”字段根据内容类型设置提醒周期比如“心肺复苏指南”每12个月提醒复核一次。顺便说句掏心窝的话做这类项目不要为了追求流量去编一些“急救偏方”比如烫伤抹牙膏、流鼻血仰头这些全是错误且可能造成二次伤害的内容。用户的一个转发动作可能影响很多人的急救行为内容上的红线比任何技术优化都重要。7. 后续扩展方向与我的真实体会系统上线跑了一段时间数据比预期好。用户收藏最多的是“海姆立克急救法”和“心肺复苏”说明大家不是不关心急救而是缺少一个能放心看、看得懂的内容入口。这让我意识到技术从来不是急救常识普及的瓶颈信任才是。后续我这边的扩展计划有三个方向场景化模拟练习用文字逐步模拟突发场景让用户自己做判断系统给反馈比单纯刷题记忆效果更好。AED网点地图对接开放地图数据帮用户在紧急时刻快速找到附近除颤仪这需要额外的数据审核和维护。与本地急救培训机构合作在课程学习完毕后展示培训报名入口让有意愿的用户接受线下实操训练。最后再分享一个小技巧如果你也在做这类知识型小程序请把所有“学习进度”和“收藏”的用户数据都做云端同步不要只用本地缓存。我见过不少同类小程序用户换手机后学习记录全没了信任感瞬间清零。哪怕后端复杂度高一点也值得一开始就做对。急救常识学习的核心不是“学完拿证”而是让普通人在需要时能想起来、敢上手。希望这篇基于微信小程序和UniApp的复盘能帮正要走同一条路的朋友减少几个晚上的折腾。
