简介这是一份面向毕业设计场景的微信小程序活动报名管理系统完整工程采用Java作为后端技术栈配以小程序前端页面覆盖活动发布、报名、收藏、评论、社团申请等常见业务模块。资源包含423个文件压缩包约57.95MB工程内以java源码、class字节码、jar依赖库、xml配置、sql数据库脚本为核心同时包含小程序端wxml/wxss页面、js逻辑、png/jpg图片素材以及html静态页面等结构清晰便于导入开发工具后对照学习。系统页面前端具备完整交互流程后端接口按控制器拆分如活动、报名、评论、收藏等可直接用于理解前后端数据交互与接口设计方式。目前已有377人学习下载经过本地编译验证配置相应环境即可运行适合正在做Java微信小程序方向课程设计或毕业设计的学生参考使用。1. 从 zip 到能跑先看清这套报名系统是什么很多人第一次拿到「微信小程序活动报名管理系统源码数据库.zip」这个压缩包时以为解压、导库、点开小程序就能跑结果通常一跑就翻车数据库建不起来中文全是乱码小程序请求接口一直失败明明还有名额提交后却超了。这套东西本质不复杂一个小程序前端一个提供接口的后端一个 MySQL 数据库脚本三样东西被打在一个 zip 里。真正花时间的是把三者的连接参数、字段逻辑和并发问题理顺。适合接外包、做内部工具、拿来做课程设计的人以及想把小程序 后端 MySQL 这条链路完整动手一遍的开发者。下面我按自己拆这种包的习惯从解压、建库、跑通到排查逐个讲。2. 拆包源码结构、页面角色与表关系拿到一个活动报名系统的源码压缩包我一般不会急着解压而是先看压缩包的大小和顶层目录名。如果包里有 node_modules 或者 vendor 这种目录说明依赖也一起打包了体积会非常大如果没有说明是干净源码启动前需要自己装依赖。2.1 先从压缩包结构判断技术栈解压用命令行比右键解压更可控尤其是文件名里带中文的时候。常见做法是unzip 微信小程序活动报名管理系统源码数据库.zip -d event-signup cd event-signup tree -L 2unzip 的 -d 参数指定解压目录避免压缩包把文件散落到当前目录tree -L 2 只显示两层目录防止 node_modules 目录刷屏。解压之后重点看三个东西小程序目录、后端目录、数据库目录。常见的小程序目录叫 miniprogram 或者 client后端目录叫 server 或 api数据库脚本一般直接放在 db/sql/ 下也可能是 init.sql。判断后端用什么写看目录里的标志性文件即可find server -maxdepth 2 -name package.json -o -name pom.xml -o -name requirements.txt 2/dev/null有 package.json 是 Node.js有 pom.xml 或 build.gradle 是 Java有 requirements.txt 是 Python有 composer.json 是 PHP。多数活动报名类的成品包走 Node.js Express 或 Java Spring Boot因为这两套和微信小程序配合最省事。注意如果解压后看到的是编译好的 dist 目录而没有源码后续改逻辑会非常痛苦所有调试都要在压缩包里改完重新打包尽量别选。还要检查小程序端目录是不是完整。一个能跑的小程序前端至少要有 app.js、app.json、pages 目录、utils 或 api 目录。没有 app.json 的目录根本不是微信小程序工程没有 utils/request.js 的包说明接口请求可能全部写在页面里后面改 baseURL 要一个页面一个页面找。参数说明有些 zip 用 GBK 压缩中文文件名Linux 下会乱码可以用 unzip -O gbk 指定编码。Windows 下的常见压缩工具一般没这个问题。很多源码包为了体积会把 .sql 文件单独放在 db 目录但偶尔会漏掉。如果 zip 里没有 .sql可以看 server 目录里有没有 init 脚本或者 README 里有没有建表语句。都没有的话就得靠后端代码里的 model 层反向推导表结构。常见做法是找到 activity、registration、user 对应的模型文件把字段名、类型、默认值汇总成建表语句。这个过程不算愉快但至少能让你识别包是故意缺文件还是漏打包。另一个信号是压缩包里的 server 目录只有 config.js 而没有 schema说明作者希望你去他的线上库拉数据这种包建议不要用于学习。2.2 用户端和管理端的功能边界微信小程序活动报名管理系统这个词重点在“管理”两个字。它不只是给用户报名用的还要给管理员维护活动、审核报名、导名单。常见样式是小程序端有普通用户入口和管理员入口管理员登录后能看到报名数据也有的把管理端做成一个独立的 Web 后台小程序只负责 C 端报名。我一般优先接受小程序内带管理入口的版本因为部署成本低不需要额外维护一套 Web 前端。用户端页面一般能拆成四个活动列表页按状态展示进行中、未开始、已结束的活动活动详情页展示时间、地点、名额和剩余名额报名表单页收集姓名、手机号、自定义字段我的报名页展示本人报名记录和审核状态。管理端则围绕两类操作活动管理创建、编辑上下架、改名额、改时间和报名管理查看名单、通过/拒绝、取消报名、导出 Excel。如果源码里连导出名单都没有这个系统只能算“报名提交系统”算不上“管理系统”。权限控制是管理端的核心。管理员表一般叫 admin字段包含 username、password_hash、role。role1 通常表示超管role2 是普通管理员。后端判断管理员身份时往往是通过请求头里的 token 去查 admin 表。很多源码的问题在于用户端和管理端共用了同一个 token但中间件只查了用户表导致管理员接口权限判断形同虚设。验证方法是在管理接口里加一行临时日志打印 req.userId 和 req.userType如果 userType 从来没出现过说明中间件根本没取到 token 解析结果。这里还要提醒一个顺序问题很多新手拿到手先把报名页样式改了结果后台没有入口可以审核最后只能用数据库直接改状态非常别扭。正确顺序是先确认管理入口在哪个页面、权限怎么控制再动用户端。我习惯先在 app.json 里看 pages 数组把页面路由全部过一遍就知道这个包是完整版还是只做了 C 端的半吊子版。2.3 关键表关系是运行前提数据库脚本是整个包的灵魂决定业务能跑到什么程度。导入之前先把 .sql 从头到尾翻一遍至少确认四张核心表用户表、活动表、报名表、管理员表。表名可能叫 member/user、activity/event、sign/registration、admin/manager不同包命名习惯不一样但关系基本一致。一个用户对应多条报名记录一个活动对应多条报名记录所以报名表里至少要有 user_id 和 activity_id 两个外键。活动表里通常有一个剩余名额字段比如 current_people 和 max_people报名表里有一个状态字段比如 0待审核 1已通过 2已取消 3已拒绝。要注意的是很多包会把用户信息直接冗余在报名表里也就是说报名表里除了 user_id 还直接存了姓名和手机号。这种做法导出名单非常方便不用 JOIN 用户表代价是用户改手机号后历史报名单里的手机号还是旧的。索引设计也在这里先看一眼。报名表最常见的两种查询是“某个活动下有哪些人”和“某个人报了哪些活动”所以至少有 idx_activity_id 和 idx_user_id或者直接建联合唯一键 uk_activity_user(activity_id, user_id)。活动表则通常按 start_time 排序列表所以 start_time 上要有索引。有些包连主键都没标这种脚本导入很顺利但一跑接口就慢因为 SELECT 会全表扫描。还有一张很常被忽略的登录日志表 login_log很多包用它判断账号是否被异地登录但本地调试不需要。先不管它只要 .sql 里有这张表导入时不要手动删掉否则某些 JOIN 查询会报 Table not found。2.4 动手前先画一张功能到表的映射在改第一行代码之前把功能映射到表和字段上。这个习惯能帮你避免改了一个字段导致另一个页面报错。比如“活动列表页要显示剩余名额”它读的是 activity 表的 current_people“我的报名页要显示活动标题”它 JOIN 的是 registration 和 activity“管理员通过报名”它更新的是 registration.status 和 activity.current_people。这层关系最好写在一个临时笔记里排查问题的时候对照着看。很多包的功能看起来一样但字段命名完全不同有的叫 people_num有的叫 member_count不画映射表很容易猜错。3. 数据库初始化从 .sql 到能连上的 MySQL活动报名系统的数据量一般不大但写入频率在报名瞬间比较集中所以数据库选 MySQL 或者 MariaDB 都行本地先用 MySQL 8.0 验证。第一步先看 .sql 文件开头如果里面有 CREATE DATABASE 和 USE 语句直接 source 整个文件如果只有 CREATE TABLE就要先建库再导入。3.1 建库与导入 .sql我习惯先手动建库再导入避免脚本里带的库名和后面代码配置的库名不一致。命令如下mysql -u root -p -e CREATE DATABASE activity_sign CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; mysql -u root -p activity_sign db/activity_sign.sql第一条语句里的 COLLATE utf8mb4_unicode_ci 指排序规则和字符集配套。活动报名系统要存中文姓名、活动标题、备注所以字符集必须用 utf8mb4而不是 utf8。utf8 在 MySQL 里最多存 3 字节遇到 emoji 或者个别生僻字会直接报 Incorrect string value。第二条命令把 .sql 文件里的表结构、初始数据、索引都执行到 activity_sign 库。导入后验证一下mysql -u root -p activity_sign -e SHOW TABLES;如果 .sql 里已经带了 USE 语句导入时就不用在命令行指定库名但还是要检查最终落到哪个库。常见翻车点.sql 是 5.7 版本导出的有些字段类型在 8.0 行为略不同但没有兼容性问题真正会报错的是 sql_mode 导致严格模式拒绝了某些默认值。遇到 Not Null 字段没有默认值但插入空值时报错基本是 sql_mode 里带了 ONLY_FULL_GROUP_BY 或者 NO_ZERO_DATE。导入前还可以先看一眼文件编码file db/activity_sign.sql正常输出会包含 UTF-8 Unicode text。如果输出是 ISO-8859 或者 ASCII但文件里又有中文说明这个 .sql 文件是用 GBK 或 Latin1 存的直接导入必然乱码。这种情况先在本地用文本编辑器转成 UTF-8再执行 SET NAMES utf8mb4 后导入。本地调试时可以在导入前查一下当前严格模式mysql -u root -p -e SELECT sql_mode;如果报错和日期、空字符串有关可以在本次会话里临时改掉严格模式但不建议全局关闭。临时改法是导入前执行 SET SQL_MODE NO_ENGINE_SUBSTITUTION;导入完成后再退出。还有一个经常踩的坑是 .sql 文件里写了 USE dbname但 dbname 包含大写字母在 Linux 下 MySQL 表名区分大小写Windows 不区分导致你本地建库名字和线上不一致后面部署时找不到表。建库名统一用小写不要用大小写混合。3.2 核心表结构剩余名额和报名状态数据库脚本质量很大程度上决定这套系统能不能扛住几百人同时报名。我建议你把注意力放在活动表和报名表的关键字段上而不是一上来就看几十行的建表语句。活动表最常见的问题是把剩余名额设计成一个单独字段 current_people每次报名时先 SELECT 出来判断小于 max_people 再 UPDATE。这个逻辑在并发下一定会超卖后面会专门讲。先看字段怎么建CREATE TABLE activity ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, title VARCHAR(200) NOT NULL, start_time DATETIME NOT NULL, end_time DATETIME NOT NULL, max_people INT NOT NULL DEFAULT 0, current_people INT NOT NULL DEFAULT 0, status TINYINT NOT NULL DEFAULT 0 COMMENT 0 未开始 1 报名中 2 已结束, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_start_time (start_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;这里的 max_people0 可以用来表示不限制人数也可以保留逻辑在代码里判断。我建议明确约定0 表示不限接口里直接放行正常限流活动必须大于 0。created_at 用 DATETIME 而不是 TIMESTAMP可以避免 2038 年问题虽然活动报名系统大概率活不到那年。报名表的核心是不允许同一个人重复报同一个活动这个约束必须放在数据库层不能只靠前端按钮置灰。加一个联合唯一键CREATE TABLE registration ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, activity_id INT UNSIGNED NOT NULL, user_id INT UNSIGNED NOT NULL, nickname VARCHAR(100) DEFAULT , mobile VARCHAR(20) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0 待审核 1 已通过 2 已取消 3 已拒绝, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_activity_user (activity_id, user_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;联合唯一键 uk_activity_user 的作用是同一用户对同一活动只能插入一条报名记录。没有这个约束代码里就算查了是否已报名并发时还是能插进去两条。status 字段的索引 idx_status 是因为管理端最常见的操作是筛出所有待审核的报名这个查询条件命中索引后会明显更快。3.3 连接配置与最小权限账号本地跑通时可以直接用 root但如果你要把这系统部署给别人演示我强烈建议建一个专用账号只给 activity_sign 库的增删改查权限。这样做有两层原因一是防止代码里把别的库误删二是即便密码泄露影响范围也只有一个库。创建账号和授权的语句mysql -u root -p -e CREATE USER signuplocalhost IDENTIFIED BY choose-a-strong-password; mysql -u root -p -e GRANT SELECT, INSERT, UPDATE, DELETE ON activity_sign.* TO signuplocalhost; mysql -u root -p -e FLUSH PRIVILEGES;这里的 localhost 限制了只有本机能用这个账号连接。如果后端和数据库不在同一台机器需要改成 % 或指定网段但远程放开 MySQL 端口一定要配合防火墙和复杂密码。连接参数也很关键建议统一这样写DB_HOST127.0.0.1 DB_PORT3306 DB_NAMEactivity_sign DB_USERsignup DB_PASSWORDchoose-a-strong-password DB_TIMEZONEAsia/Shanghai在 JDBC 连接串里常见配置是 useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai。serverTimezone 必须和服务器时区一致否则时间字段会差 8 小时。Node.js 的 mysql 连接池则要注意 charset 和 dateStrings 参数dateStrings: true 可以避免时间被转成本地时区后格式错乱。如果你用 MySQL 8.0 的 caching_sha2_passwordNode.js 旧版本 mysql2 可能连不上需要升级 mysql2 到 2.x 以上或者在初始化时把密码认证改成 mysql_native_password。4. 本地跑通后端接口、小程序请求与一次完整报名后端能不能启动90% 取决于数据库连接信息。拿到代码后第一步去根目录找几个常见配置文件.env、config/default.json、application.yml 或 application.properties把库名、账号、密码改成上面建好的。4.1 后端启动前要改的配置Node.js 项目的 .env 一般长这样DB_HOST127.0.0.1 DB_PORT3306 DB_NAMEactivity_sign DB_USERsignup DB_PASSWORDchoose-a-strong-password JWT_SECRETreplace-with-a-long-random-string PORT3000JWT_SECRET 是登录态签名的密钥很多包默认写死成 admin123上线前必须换。这里先把 PORT 记下小程序端要连的接口地址就是 http://127.0.0.1:3000。改完配置后启动cd server npm install npm run dev如果 package.json 里没有 dev 脚本就换成 npm start。启动后先在浏览器或命令行验证健康检查接口一般会有 /api/health 或 / 返回 ok。如果报 ECONNREFUSED说明数据库没起来或者端口不对报 ER_ACCESS_DENIED_ERROR 就是账号密码或授权不对回到上一章的 grant 语句重新授权。如果报 MODULE_NOT_FOUND说明 npm install 没装完整删掉 node_modules 重新装。启动日志里如果出现连接失败而不是端口已监听重点查 .env 有没有被程序真正读到。很多包同时存在 config.js 和 .env后者优先级更高但代码里可能只读前者。这里还要提一个我经常看到的坑管理端接口鉴权和用户端接口鉴权常常混在一起。用户登录用的是 member 表管理员登录用的是 admin 表两个 token 如果共用同一个 secret 也没关系但后端中间件不能拿用户 token 去查 admin 表。拿到源码后先在接口前加日志或者看中间件的查询表名确认管理接口的数据源否则会出现管理员登录成功但接口返回权限不足的怪问题。4.2 小程序端的 baseURL 与请求封装小程序端最容易被忽略的就是接口地址。默认安装包通常把 baseURL 写成 https://example.com/api 或者某个旧服务器的域名本地跑必须改。在 app.js 的 globalData 里改App({ globalData: { baseUrl: http://127.0.0.1:3000/api } })然后在 utils/request.js 里封装一个带 token 的请求方法const request (url, method GET, data {}) { const token wx.getStorageSync(token) return new Promise((resolve, reject) { wx.request({ url: getApp().globalData.baseUrl url, method, data, header: { Content-Type: application/json, Authorization: token ? Bearer token : }, success: res resolve(res.data), fail: err reject(err) }) }) }这里的 Authorization 是后端做登录鉴权用的不是所有包都叫这个名字有的用 token 字段直接放在 header。你先看后端鉴权中间件读的是哪个 key再对应改 header。小程序开发工具右上角一般要勾选“不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书”否则本地 http 请求会被拦下来报 request 的 url 不在合法域名列表中。真机预览时也要在手机端打开调试模式或者把本机 IP 暴露到同一局域网用。手机和电脑连同一个 Wi-Fi再把 baseUrl 改成 http://192.168.x.x:3000/api 即可。登录态这块也顺便检查一下。小程序端一般通过 wx.login 拿到 code再传给后端换 openid 和自定义登录态 token。如果你发现后端没有 wx.login 相关接口那么这个系统可能是纯账号密码登录不需要走微信登录。两种都正常只是本地测试方式不同账号密码登录要先去注册页面造一个用户openid 登录则要在开发者工具里保证 appid 是真实可用的。很多源码包拿不到真实 appid个人开发者申请的小程序没有相应权限时接口会返回 code 错误。4.3 一次报名请求的完整链路跑通报名接口是检验整套配置最直接的方式。前端在报名页点击提交后发送 POST 请求把活动 ID 和表单字段传给后端。核心代码如下signUp(activityId, formData) { return request(/signup, POST, { activityId, mobile: formData.mobile, nickname: formData.nickname }) }后端接口不能只是插入一条报名记录必须处理三个边界活动是否存在、是否在报名时间内、名额是否已满。用 Node.js 伪代码表示如下app.post(/api/signup, async (req, res) { const { activityId, mobile, nickname } req.body const conn await pool.getConnection() try { await conn.beginTransaction() const [activity] await conn.query( SELECT id, max_people, current_people, status FROM activity WHERE id ? FOR UPDATE, [activityId] ) if (!activity || activity.status ! 1) { throw new Error(活动不存在或不在报名时间内) } if (activity.max_people 0 activity.current_people activity.max_people) { throw new Error(名额已满) } const [result] await conn.query( UPDATE activity SET current_people current_people 1 WHERE id ? AND (max_people 0 OR current_people max_people), [activityId] ) if (result.affectedRows 0) { throw new Error(报名人数已达上限) } await conn.query( INSERT INTO registration (activity_id, user_id, mobile, nickname) VALUES (?, ?, ?, ?), [activityId, req.userId, mobile, nickname] ) await conn.commit() res.json({ code: 0, message: 报名成功 }) } catch (err) { await conn.rollback() res.status(400).json({ code: 1, message: err.message }) } finally { conn.release() } })这段代码的关键在于先锁行再更新名额再插入报名。SELECT ... FOR UPDATE 会把这一行活动记录锁住避免两个请求同时读到同一个剩余名额。UPDATE 语句里又带了一次 current_people max_people 条件即使前面的 SELECT 没拦住数据库也会在这里挡住超卖。事务保证如果插入失败名额会回滚。如果你拿到的源码是先 SELECT 判断再 INSERT没有事务的写法务必改成上面这种风格这是活动报名系统最值得改的一处。报名时间的判断也值得注意。很多接口只判断 activity.status但 status 可能在后端定时任务里更新本地没有定时器时状态永远不变。正确的做法是直接用 start_time 和 end_time 判断当前时间是否落在报名窗口内。这样即使活动刚创建、状态还是 0只要时间到了用户就能报名。5. 避坑排查五个让系统翻车的典型问题5.1 环境配置类中文乱码、请求域名校验失败现象数据库导入后中文全部变成问号或者小程序一请求接口就报“不在合法域名列表中”。这两个问题几乎每个拿到源码的人都会遇到至少一个。原因中文乱码是连接字符串的字符集和数据库实际字符集没对齐。导入工具或客户端用了 latin1但表是 utf8mb4传输过程就丢了。域名校验失败则是微信开发者工具默认对网络请求做了校验本地 http 接口没有在公众平台配置合法域名。解决乱码先看三处是否一致数据库字符集、JDBC/连接参数的 characterEncoding、程序里的 SQL 文件存储编码。导入前在 mysql 命令行执行 SET NAMES utf8mb4; 再 source。域名校验在开发阶段直接在开发者工具详情里勾选“不校验合法域名”这一步做了能省非常多时间。如果真机也要调把后端接口地址从 127.0.0.1 换成电脑在局域网内的 IP并确认防火墙放行端口。小程序端每次修改 baseUrl 后要重新编译不然 globalData 里缓存旧地址的问题会让人误以为代码没生效。5.2 业务逻辑类超卖、取消不回退、登录态失效现象一个 50 人的活动后台最终有 55 条通过记录或者用户取消报名后剩余名额没有增加再或者小程序用着用着突然返回“未登录”但用户明明没退出。这三条是报名系统的老毛病。原因超卖几乎都是因为代码没有事务和行锁多个请求同时读到 current_people49都认为还能报结果全插进去了。取消不回退是因为取消操作只改了报名表 status没有同步更新活动表 current_people。登录态失效则多半是 token 过期后小程序没有统一处理还在拿旧 token 发请求。解决超卖改成像 4.3 那样的事务代码重点用 UPDATE ... WHERE current_people max_people 的 affectedRows 判断。取消报名时把状态改成 2同时做 UPDATE activity SET current_people current_people - 1 WHERE id ?中间套事务且要做好“取消只对已通过的记录生效”避免重复回退出负数。登录态失效在 request.js 的 response 里统一判断 code如果是 401 或约定好的未登录状态就清掉本地 token 并跳转到登录页而不是让用户看到一行看不懂的报错。验证方法我一般用并发请求本地接口。比如用 curl 连续发出 60 个报名请求for i in $(seq 1 60); do curl -s -X POST http://127.0.0.1:3000/api/signup \ -H Authorization: Bearer $TOKEN \ -H Content-Type: application/json \ -d {\activityId\:1,\mobile\:\138000000${i}\,\nickname\:\user${i}\} done wait跑完以后查报名表数量如果超过 max_people说明事务代码没生效如果刚好等于才算过关。这个测试还能帮你顺手发现另一个问题报名表里可能混入重复的手机号需要确认 unique 约束是不是只在 activity_id user_id 上没有限制同一个手机号多次报名。5.3 数据库导入失败root 密码绕不开和 SQL 严格模式现象mysql -u root -p 连接时提示 Access denied或者导入时报“Data too long” / “Incorrect decimal value”。原因本地 MySQL root 密码不对是第一个原因这个只能靠重置密码或者用正确的账号。Data too long 很多时候不是真的字段长度不够而是严格模式没收住非法默认值比如 DATETIME 字段给了一个 0000-00-00 00:00:00。解决临时会话可以 SET sql_mode 再导入正式配置建议把 .sql 里的非法默认值改成 NULL 或合法日期不要长期关闭严格模式。报 Import error 的时候先看具体的行号和列名直接打开文件搜索那个字段八成是版本差异。另一个经常踩的坑是 .sql 文件里写了 USE dbname但 dbname 包含大写字母在 Linux 下 MySQL 表名区分大小写Windows 不区分导致你本地建库名字和线上不一致后面部署时找不到表。建库名统一用小写不要用大小写混合。跑完导入后MySQL 的错误日志通常在 /var/log/mysql/error.logWindows 下在数据目录的 hostname.err 里。先打开日志看具体的 SQL 语句再去 .sql 文件里搜索对应表确认是哪条语句被严格模式拒绝。查日志比盯着终端报错更靠谱终端只显示第一条错误日志能看到上下文。5.4 排查报名接口问题的一个通用顺序接口报错时不要先看前端 console按“后端日志 → 数据库连接 → 参数传递 → 业务条件”顺序走。后端控制台会输出 SQL 语句和错误码如果只有前端报后端没日志说明请求根本没到后端先看端口、看 host。如果 SQL 报语法错误再检查 .sql 字段和代码里字段名是否对得上很多包在打包时把表名改了但代码没跟着改。最后才是业务条件比如 status 判断写反了。按这个顺序能避免在开发者工具和控制台之间反复横跳。6. 进阶从“能报名”到“能运营”的三个能力如果你已经跑通报名下一步不是加花哨动画而是补运营视角的功能。我最先会做的是报名名单导出后端查 registration 和 activity输出 CSV并且要加 UTF-8 BOM否则 Excel 打开中文会乱。CSV 的字段如果来自用户填的表单还要把等号开头的字符串前面加单引号防止公式注入。导出接口的默认过滤条件只包含状态为“已通过”的记录把“已取消”和“已拒绝”的混进去线下通知会非常尴尬。第二件事是订阅消息通知。微信小程序只能用模板消息触达用户用户报名时必须勾选允许订阅才能在他报名成功后收到“报名成功审核通过”的通知。好好利用这一点用户体验会远超“只能在小程序里查状态”。如果管理员拒绝报名也尽量发一条通知否则用户不知道自己的名额有没有着落。第三件事是把本地地址改成线上。baseURL 换成已备案域名下的 HTTPS 地址后端用 Nginx 反代理到本机端口MySQL 改到内网并每天备份 activity_sign 库。我自己经历过一个教训帮某组织部署好系统后对方点名要导出名单我才发现源码里的导出功能把状态为“已取消”的用户也导进了 Excel导致线下通知多发了几十个名额。后来我把导出的默认过滤条件改成只导“已通过”才算收尾。希望帮到你。本文还有配套的精品资源点击获取
