简介：这是一份清明祈福祭祀墓园系统的后端源码包，定位于服务祭扫类网站的逻辑层，面向需要实现祈福记录、祭祀预约、留言管理等功能的开发者。压缩包共135个文件，主要由54个HTML页面模板、29个PHP业务脚本、16个JavaScript交互脚本、9个CSS样式表及20个PNG图片等构成，整体大小仅5.28MB，结构清晰便于部署与二次开发。目前已有1697人学习，说明其具备一定的参考热度。源码覆盖了后端常见知识点，包括数据库连接与增删改查、RESTful风格API设计、用户输入过滤与安全防护、错误日志记录等，并附有前端展示所需的页面与样式，适合PHP后端初学者或需快速搭建祭扫系统的开发者借鉴。通过阅读该源码，可快速了解一套完整祭祀业务的后端运行流程，并在此基础上扩展支付、短信通知等功能。

1. 清明祈福祭祀墓园后端源码：2.0.8 到底解决什么场景，适合谁来接手

清明前一周，殡葬服务平台的运营开始焦虑：访问量翻了十倍，祭祀记录写入快到数据库连接池告警。这时候手里如果有一套清明祈福祭祀墓园源码的后端，版本 2.0.8，意味着它能直接支撑起「网上祭祀」这类业务——用户注册、创建家庭纪念馆、上传逝者照片与生平、在线献花点烛祈福、写悼念词，后台审核再上墙。后端部分的核心不在页面多好看，而在于纪念馆生命周期管理、祭祀记录高并发写入、审核闭环和内容安全这几件事。适合读这篇文章的人：拿到 2.0.8 源码要自行部署的运维、接祭祀类私活的后端开发，以及想从 CRUD 加审核加定时任务的典型项目练手的人。

2. 先把后端模块拆清楚：家庭纪念馆、祭祀记录与内容审核的领域建模

2.1 核心业务实体与表结构设计：六张表撑起整个平台

网上祭祀平台的后端，表面看是三个模块，真正拆开是六张核心表：用户表、纪念馆表、祭祀记录表、悼念留言表、祭品表、订单表。很多新手拿到 2.0.8 后端第一件事是找登录注册代码，其实先把表结构读明白，后面所有接口都顺了。

用户表比常见的用户表多一个字段：relation，也就是当前用户和逝者的关系，儿子、女儿、孙辈、朋友。这个字段直接影响纪念馆的创建权限。很多平台规定一个逝者只能建一个主纪念馆，亲属只能加入，只有第一位创建者能改生平。relation 为空的人，只能提交「申请绑定家属关系」，由馆主审核。

纪念馆表是整个业务的地基。下面这份建表语句几乎是这类项目的标准形态：

CREATE TABLE `memorial` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `name` varchar(50) NOT NULL COMMENT '逝者姓名', `cover` varchar(255) DEFAULT NULL COMMENT '封面图URL', `birth_date` date NOT NULL COMMENT '出生日期', `death_date` date NOT NULL COMMENT '逝世日期', `intro` varchar(1000) DEFAULT NULL COMMENT '生平简介', `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0草稿 1审核中 2已上线 3已关闭', `creator_id` bigint(20) NOT NULL COMMENT '创建人ID', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_identity` (`name`,`birth_date`,`death_date`), KEY `idx_status` (`status`), KEY `idx_creator` (`creator_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='纪念馆主表';

这段 DDL 里，唯一索引uk_identity落在(name, birth_date, death_date)上，是防重名的第一道闸。但这是一把双刃剑：如果全网有两个同名同姓且出生、忌日都一样的人，第二个纪念馆就建不出来，所以第 3 章会讲怎么用「家属关系」破这个锁。status状态机是审核流程的地基，从 0 草稿到 3 已关闭，每次状态流转都要写审计日志，方便出纠纷时回溯。creator_id上建普通索引就够了，这个表不需要覆盖索引，查询都是单条按 id 拿。

祭祀记录表是写入量最大的一张，清明当天单接口 QPS 冲几百很正常：

CREATE TABLE `worship_record` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `memorial_id` bigint(20) NOT NULL COMMENT '纪念馆ID', `user_id` bigint(20) NOT NULL COMMENT '祭祀人ID', `type` tinyint(4) NOT NULL COMMENT '1献花 2点烛 3祈福 4供品', `amount` int(11) NOT NULL DEFAULT '1' COMMENT '数量', `unit_price` decimal(10,2) DEFAULT '0.00' COMMENT '单价（供品商城用）', `remark` varchar(200) DEFAULT NULL COMMENT '备注', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '祭祀时间', PRIMARY KEY (`id`), KEY `idx_memorial_time` (`memorial_id`,`create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='祭祀记录表';

idx_memorial_time这个联合索引是列表页的命脉。前台高频查询是「某个纪念馆最近 20 条祭祀动态」，(memorial_id, create_time)直接覆盖。type字段用 tinyint 枚举而不是字符串，是为了省空间，也方便统计接口做 group by。unit_price虽然现在大概率用不上，但祭品商城一旦上线，对账就要靠它，这是血泪经验，前期不埋这个字段后期只能改表。

2.2 后端技术栈选型：为什么这类项目不推荐一上来就拆微服务

这类源码最稳妥的落地形态是单体内核加若干扩展组件。我经手的 2.0.8 这类版本，绝大多数是 Spring Boot 2.x 或者 PHP Laravel 写的，配 MySQL 8 和 Redis。选择单体的理由很直接：整个平台的核心链路是「创建纪念馆 -> 审核 -> 提交祭祀记录 -> 展示」，数据模型高度内聚，拆成微服务只会把事务问题复杂化。真正要拆的是 Redis 缓存和消息队列，这两个是给清明前后那波峰值流量准备的，不是给业务拆的。

技术栈里必装的组件是 Redis。除了做 Session 和验证码缓存之外，它最实在的用途是扛祭祀记录的短时峰值。用户点一次献花，本质是往祭祀记录表插一行。清明那天全站的人都集中在上午操作，数据库连接池很容易被打满。常见做法是先把祭祀记录推到 Redis 的 list 里，做一个简单的异步落库，后面我会给出代码。

Java 侧用 Spring Boot 的话，持久层建议用 MyBatis-Plus。祭祀项目表结构多、单表 CRUD 占比高，MyBatis-Plus 能少写很多模板代码。没必要上 JPA 那种重型方案，祭祀项目的查询条件经常是「纪念馆 id + 日期范围 + 类型」，和 JPA 的强项没有太大关系。当然如果源码本身就是 Laravel，那就用 Eloquent，别强行换语言重写。

2.3 前后端分离与接口权限：后端接口设计的边界在哪

这类源码的前端可能是 Vue 或小程序，后端接口设计有几个固定套路。首先，所有写操作接口必须要求登录态，用 Token 而不是 Session。因为祭祀类平台要接微信小程序，Token 放在 header 里传，比 Session 的 cookie 传法在跨端上省事得多。其次，纪念馆的创建和编辑接口，必须做数据权限校验：用户只能操作自己创建的纪念馆，或者绑定了亲友关系的纪念馆。这块如果漏了，就会出现 A 用户把 B 用户家祖先的生平改掉的事故，属于很严重的线上数据事故。

跨域配置也要在网关层统一做。前端域名是 www.example.com，后端接口域名是 api.example.com，开发环境下后端必须配置 CORS 白名单，而不是粗暴地加allowedOriginPatterns("*")。祭祀平台要走微信支付或者支付宝支付，支付回调接口的域名是固定的，通配跨域会把支付回调都放进来，后果很严重。

我习惯把接口版本号放在路径里，/api/v1/memorial/，这样 2.0.8 这类版本迭代的时候，后端不用把旧接口全删掉，留一份 v1 给老端、新版本走 v2，过渡平滑。路径上同时区分管理端和用户端，/api/admin/memorial/和/api/user/memorial/，管理端接口多一道角色校验切面，两个端的事故不会互相殃及。

3. 后端核心链路落地：创建纪念馆到提交祈福记录的接口实现

3.1 创建纪念馆接口：亲属关系校验与唯一性约束

创建纪念馆的接口是整个后端最不能出错的地方。需求一般是「一个逝者对应一个主纪念馆」，但是同名同姓的人很多，单靠姓名去重一定会出冤案。常见处理方案是「姓名 + 出生日期 + 逝世日期 + 家属手机号」四元组去重，其中家属手机号是关键置信维度。一个 2.0.8 版本的后端，这里大概率落一张辅助关系表，主体表建唯一索引在 (name, birth_date, death_date) 上，家属手机号作为辅助判断。也就是说，即使姓名和日期完全一样，只有家属本人能创建，外人撞名也创建不了第二个。

// MemorialCreateService.java —— 创建纪念馆的核心逻辑 @Override @Transactional(rollbackFor = Exception.class) public Long createMemorial(CreateMemorialRequest req, Long userId) { // 1. 先查唯一约束：姓名+出生日期+逝世日期 是否已存在纪念馆 LambdaQueryWrapper<Memorial> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Memorial::getName, req.getName()) .eq(Memorial::getBirthDate, req.getBirthDate()) .eq(Memorial::getDeathDate, req.getDeathDate()); Memorial exists = memorialMapper.selectOne(wrapper); // 2. 已存在则校验亲属关系，未绑定则提示申请人提交关系证明 if (exists != null) { Integer relation = memorialRelationMapper .selectRelation(userId, exists.getId()); if (relation == null || relation == 0) { throw new BizException("该纪念馆已存在，请先申请绑定家属关系"); } memorialRelationMapper.insert(userId, exists.getId(), "family"); return exists.getId(); } // 3. 不存在则新建，并把创建人设为管理员角色 Memorial memorial = new Memorial(); memorial.setName(req.getName()); memorial.setBirthDate(req.getBirthDate()); memorial.setDeathDate(req.getDeathDate()); memorial.setStatus(1); // 待审核 memorialMapper.insert(memorial); memorialRelationMapper.insert(userId, memorial.getId(), "owner"); return memorial.getId(); }

这段逻辑里，事务注解@Transactional(rollbackFor = Exception.class)不是随便加的。它保证「查询是否重复」和「插入纪念馆」两个动作要么都成功、要么都回滚，防止在并发下两个人同时创建出两条重复纪念馆。第 2 步查关系的方式，是防止同名同姓生日又一样的乌龙。参数上要给req.getName()做长度和特殊字符过滤，悼念场景用户上传的名字偶尔会带句号、逗号这种标点，后端不拦的话，前台页面渲染时 XSS 风险很高。

这里有一个容易忽略的并发细节：selectOne本身不是锁，两个请求同时进来，都可能查到「不存在」，然后都走到 insert。所以(name, birth_date, death_date)的唯一索引是硬兜底，数据库层直接拒绝第二条插入，代码里再捕获DuplicateKeyException，转成友好提示。索引兜底和代码判断缺一不可。

3.2 祭祀记录写入接口：Redis 队列做缓冲，数据库做落账

清明当天早上八点到十点，是祭祀平台写入的高峰。如果每次都直接把记录 insert 进 MySQL，数据库连接池 100 个连接很快被打满。常见做法是把写入变成异步：先写 Redis list，再用一个后台任务慢慢往 MySQL 刷。

// MemorialWorshipService.java —— 祭祀记录异步写入 public void recordWorship(WorshipRequest req, Long userId) { // 1. 参数校验：纪念馆id和祭祀类型不能为空 if (req.getMemorialId() == null || req.getType() == null) { throw new BizException("祭祀参数不完整"); } // 2. 构造消息体，塞进Redis list，key按纪念馆id分片 String key = "worship:queue:" + (req.getMemorialId() % 16); String json = JSON.toJSONString(WorshipMessage.build( userId, req.getMemorialId(), req.getType(), req.getAmount(), req.getRemark(), System.currentTimeMillis())); redisTemplate.opsForList().rightPush(key, json); // 3. 立刻返回，前端可以展示“祈福成功”的动效 // 真正落库由 @Scheduled 任务每秒批量刷一次 } // 后台落库任务：每5秒批量刷一次，减少数据库抖动 @Scheduled(fixedDelay = 5000) public void flushWorshipQueue() { for (int i = 0; i < 16; i++) { String key = "worship:queue:" + i; List<String> batch = redisTemplate.opsForList().leftPop(key, 200); // 批量insert，这里用MyBatis-Plus的insertBatchSomeColumn if (batch.size() > 0) { worshipRecordMapper.insertBatchSomeColumn(batch); } } }

这里有个关键参数：rightPush和leftPop的组合，天然是先进先出的队列。用分片 key 是为了避免单个 Redis list 过长导致在 pop 时阻塞，分 16 片能让读取和写入并行。批量刷库的 200 条一次，是兼顾单次事务大小和数据库连接占用，200 条以内的 insert 事务在 MySQL 上耗时通常在 2 毫秒上下，不会拖垮主库。fixedDelay = 5000表示上一次任务执行完毕后再等 5 秒，避免批量任务和下一次重叠；如果用fixedRate，固定每 5 秒触发一次，上一次没跑完就会堆任务，这里不推荐。

坑在哪儿呢？如果 Redis 里的数据丢了，祭祀记录会全部消失。所以这个方案只做缓冲，不做持久化。要么在写入 Redis 的同时把消息也发一份到本地文件，要么在用户请求侧加一个兜底的补偿任务：每 5 分钟扫一次 Redis 队列长度，如果积压超过阈值，就降级成同步写入。兜底逻辑虽然不常触发，但清明当天必须开着。

3.3 悼念留言与内容审核：不能直接把用户输入推上线

祭祀平台的悼念留言是敏感内容的高发区，不只是政治敏感，还有针对逝者家属的攻击和灵异恐怖内容，审核必须做闭环。后端至少要设计成「先审后上」：用户提交留言后，状态立刻设成 1（待审核），审核通过才置为 2（已发布）。如果嫌审核人力贵，可以用关键词过滤加人工抽审的混合策略，但悼念词不能只靠关键词。

CREATE TABLE `memorial_message` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `memorial_id` bigint(20) NOT NULL COMMENT '纪念馆ID', `user_id` bigint(20) NOT NULL COMMENT '留言用户ID', `content` varchar(500) NOT NULL COMMENT '悼念词内容', `is_public` tinyint(4) NOT NULL DEFAULT '1' COMMENT '1公开 0仅亲友可见', `audit_status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '1待审核 2已发布 3已驳回', `auditor_id` bigint(20) DEFAULT NULL COMMENT '审核员ID', `audit_time` datetime DEFAULT NULL COMMENT '审核时间', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_memorial_id` (`memorial_id`), KEY `idx_audit_status` (`audit_status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这条建表语句有几个值得注意的设计点。content用 varchar(500)，悼念词超过 500 字的直接截断。is_public单独一个字段，和audit_status分开，因为「是否公开」是用户主动选择，而「是否通过审核」是平台动作，两个维度混在一个字段里，后期统计公开留言量时就会翻车。索引建memorial_id和audit_status两个普通索引，覆盖了列表页和审核页的查询路径；如果列表要按时间排序，再加一个(memorial_id, create_time)联合索引，不要无脑组合。

审核接口必须做「先锁后审」。管理员点击通过，后端要先把这条留言的audit_statusupdate 成已发布，再更新纪念馆的last_message_time。如果两个动作不加事务，就会出现留言已发布但列表页时间戳没刷新的问题，用户会看到一条「时间对不上」的记录。审核驳回时注意留下驳回原因字段，不然用户不知道为什么自己写的悼念词没上墙，体验很差。

4. 后端部署与配置：数据库、文件存储与 HTTPS 的必改项

4.1 配置文件逐项解读：数据源、Redis 连接池与密码注入

把 2.0.8 的源码拿到手，第一步不是急着跑mvn spring-boot:run，而是核对配置文件。祭祀项目的application.yml里至少有五组配置必须改：数据库连接、Redis 连接、文件存储路径、HTTPS 证书路径、日志级别。最常见的问题是把开发环境的配置直接带到了生产环境，数据库密码、Redis 密码、上传路径全部带包上线，这是最严重的事故。

# application-prod.yml —— 生产环境关键配置 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/jisi?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: jisi_prod password: ${DB_PASSWORD} hikari: maximum-pool-size: 30 minimum-idle: 10 connection-timeout: 10000 redis: host: 127.0.0.1 port: 6379 password: ${REDIS_PASSWORD} timeout: 3000ms lettuce: pool: max-active: 100 max-idle: 50 min-idle: 10 file: upload-dir: /data/jisi/uploads max-size: 10MB allowed-ext: jpg,jpeg,png,gif,mp4 logging: level: com.example.jisi: debug org.springframework.web: warn

数据源里useSSL=false不是让你裸奔，而是配置阶段先排除证书干扰；等 HTTPS 证书在网关层配好后，数据库连接走内网，可以不加密。如果数据库暴露在公网，不能这样配。maximum-pool-size: 30是中小型祭祀平台的安全值，默认 10 个连接清明那天会被瞬时流量打爆，但也不建议超过 50，连接池太大反而在短事务高并发下争抢 CPU。

Redis 的max-active: 100和前面的 16 片队列是对应的。如果 Redis 连接池太小，祭祀队列的 rightPush 和 leftPop 会互相堵；如果太大，Redis 本身 CPU 又是瓶颈。100 是这个体量下比较稳的平衡值。所有密码都走${DB_PASSWORD}环境变量引用，所有配置文件里凡是涉及密码的配置都别写明文，拿到手第一件事是全局搜password:改成占位符形式。

以下是配置项的速查参考：

4.2 首次启动顺序：先建库、再迁数据、最后起服务

后端部署最常见的失败是启动报错，看日志发现是表不存在。因为这类源码很多依赖初始化 SQL 脚本，而不是自动建表。拿到手后，先在 MySQL 里执行一遍docs/sql/init.sql，把库和基础表结构建好，再去执行docs/sql/seed.sql灌入默认的管理员账号和祭品分类数据。在 Spring Boot 里，我的习惯是使用 Flyway，把 SQL 脚本放到src/main/resources/db/migration/目录下，版本号从V1__init.sql开始命名。这样 2.0.8 升级到 2.1.0 时，直接新增一个V2__add_xx.sql，不用每次手工比对表结构。

# 首次部署（说明启动顺序） mysql -u root -p jisi < docs/sql/init.sql mysql -u root -p jisi < docs/sql/seed.sql # 确认表结构数量符合预期 mysql -u root -p -e "SHOW TABLES FROM jisi;" | wc -l # 再启动后端服务 nohup java -jar jisi-backend-2.0.8.jar \ --spring.profiles.active=prod \ --spring.datasource.password=xxx \ --spring.redis.password=xxx \ > /data/logs/jisi.log 2>&1 &

这个顺序不能反。先起服务再建表的话，Spring Boot 的启动过程在做数据源检查时会直接报错退出，虽然报错信息里会提示表不存在，但后面依赖初始化数据的模块还挂着，排查成本更高。--spring.profiles.active=prod指定生产配置，命令行参数优先级高于 application.yml，SQL 里的敏感信息不会出现在进程命令行里。

还有一个容易忽略的点：nohup启动时一定要切到项目目录下再执行，或者设置--spring.config.additional-location=file:/data/config/application-prod.yml，避免 Spring Boot 因为找不到资源目录下的配置文件而死。日志文件路径/data/logs/必须先创建好，否则服务启动后日志无处可写，进程可能假死。

4.3 静态资源与图片分离：纪念馆照片不该和后端包在一起

祭祀平台里有大量逝者照片和生平图。照片、视频这类静态资源，最忌讳直接放在 Spring Boot 的src/main/resources/static/下面。第一，内置 Tomcat 对静态文件的读取是串行的，并发一大就卡；第二，打成的 jar 包越来越大，版本升级时整个包都要重新传；第三，图片被误删或损坏时，后端 jar 也要跟着回滚。

2.0.8 这类源码在部署文档里通常会写「把 uploads 目录映射到 Nginx」，这是正路。后端配置里file.upload-dir: /data/jisi/uploads，Nginx 配置一个 location 直接指向这个目录：

server { listen 443 ssl; server_name www.jisi-example.com; ssl_certificate /etc/nginx/certs/fullchain.pem; ssl_certificate_key /etc/nginx/certs/privkey.pem; location /uploads/ { alias /data/jisi/uploads/; expires 7d; add_header Cache-Control "public, max-age=604800"; access_log off; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; } }

关键参数是expires 7d和Cache-Control。纪念馆封面和生平图改动频率很低，缓存 7 天能省掉大量重复请求。但这里有个取舍：如果用户上传新照片后立刻想看到效果，7 天缓存会让他觉得平台出 bug 了。常见做法是后端在上传接口返回的 URL 里加一个版本参数，比如/uploads/photo/1001.jpg?v=20250401，前端更新图片时带上新的时间戳，后端不用动 Nginx 缓存策略就能强制刷新。

HTTPS 证书那部分，很多新手把证书配置写在 Spring Boot 里，也就是 application.yml 里配server.ssl.*。虽然能跑，但我强烈建议把证书放在 Nginx 这层终止，后端继续用 HTTP。原因是证书续期、更换、多域名绑定的操作都在 Nginx 层做，不需要重启 Java 进程。对清明这种要求高可用的场景，Nginx 热加载证书比重启后端进程安全得多。

5. 清明祭祀后端避坑：5 条值得写进运维手册的踩坑记录

踩坑记录按现象、原因、解决三段式写，方便直接抄进你自己的运维手册。

5.1 同一个纪念馆被重复创建，后台出现「双胞胎」

现象：用户在清明前创建纪念馆时点了一次提交，页面卡顿后又点了一次，结果后台出现两条一模一样的纪念馆记录，并且都处于「审核中」状态。

原因：前端没有做防重复提交，后端创建接口也没有做幂等控制。前端按钮虽然置灰了，但后端接口本身没有对同一个时间窗口内的重复请求做拦截。

解决：创建接口增加request_id幂等参数。前端在点击创建时生成一个 UUID，后端在 Redis 里以memorial:create:{request_id}做 setnx，有效期 30 秒，如果已经存在则直接返回第一次创建的结果。这个方案比单纯的前端按钮置灰可靠，因为移动端弱网重试很容易绕过按钮限制。同时每天跑一次重复数据检查：SELECT name, birth_date, death_date, COUNT(*) FROM memorial GROUP BY name, birth_date, death_date HAVING COUNT(*) > 1;，有异常就提醒人工处理。

5.2 清明当天祭祀记录接口突然变慢，数据库 CPU 飙高

现象：清明节当天上午十点左右，祭祀记录提交接口响应时间从 50ms 涨到 2 秒，MySQL CPU 持续 80% 以上。

原因：当天所有用户几乎同时操作，祭祀记录表worship_record的写入量是平时的 30 倍，加上查询列表页时每次都 count 一次全表，MySQL 的 buffer pool 被 count 操作和大量 insert 挤爆。

解决：两条路同时走。一是把祭祀记录写入改成 Redis 队列异步落库，也就是第 3 章那个方案，让 MySQL 每秒最多接收 200 条批量写入，不会暴涨；二是列表页的分页不用SELECT COUNT(*)算总页数，改成「最多加载前 500 条，超出提示用户继续滚动加载」，祭祀平台根本不需要精确的总条数。压测时要专门盯着这两个点，任何一个失守都会在清明现场翻车。

5.3 用户上传的图片是 .jpg 改名的 .php，后台被上传木马

现象：纪念馆图片上传接口能正常上传 .jpg，但攻击者把一个 php webshell 改名为 .jpg 传上去，然后在其他接口构造路径把它 include 执行，服务器被拿下。

原因：图片校验只看了扩展名，没有校验文件头内容；文件存储路径和上传入口暴露在公网，Nginx 也没有对可执行脚本做拦截。

解决：后端上传接口增加文件头校验，.jpg必须校验FF D8 FF E0，.png校验89 50 4E 47，不匹配直接拒绝。存储目录放在 Web 根目录之外，由独立的上传服务处理；Nginx 里对/uploads/明确location ~ \.(php|jsp)$ { deny all; }，把执行脚本的可能直接掐死。上传接口还要限制文件大小和同时上传数量，不然清明当天有人拿脚本并发传图，磁盘会被瞬间打满。

5.4 悼念留言审核通过后，前台永远刷不出来

现象：管理后台把一条悼念留言审核通过后，前台纪念馆详情页仍然显示「暂无留言」。

原因：前台列表查询条件里带了audit_status = 2，但留言表的数据在插入时audit_status默认为 1，审核通过时只改了数据库里的字段，前台列表接口的缓存还在沿用旧数据，没有主动失效。

解决：Redis 缓存要按业务维度设计 key，比如memorial:message:{memorial_id}，审核通过或驳回时调用redisTemplate.delete(key)主动清缓存，而不是依赖 TTL。更稳的做法是前台列表接口直接读数据库加二级缓存，审核操作后只清二级缓存，避免清 Redis 和清库不一致。

5.5 跨域配置用了通配符，支付回调接口被刷爆

现象：项目上线后，支付回调接口频繁报验签失败，后台日志显示一堆非支付平台来源的请求。

原因：后端为了开发方便配了allowedOriginPatterns("*")，结果支付回调接口也被当成了跨域请求，所有来源都放行，攻击者用伪造来源刷回调。

解决：把 CORS 配置收敛成白名单模式，只允许前端域名跨域访问/api/路径，支付回调路径单独放行，并且对该路径做来源 IP 校验。CORS 白名单不是加了就完事，要定期检查是否有新域名被误加进白名单。这里补充一个排查优先级：如果清明当天同时出现接口变慢和 Redis 连接池报错，先看 Redis 队列积压量，再看 MySQL 慢查询，最后看网络带宽。队列积压决定数据会不会丢，慢查询决定页面卡不卡，带宽决定用户能不能打开页面。这个顺序是踩坑踩出来的，别反过来。

6. 让 2.0.8 后端扛住清明流量：三层缓存与数据归档的落地做法

祭祀平台的流量特征很鲜明：平时是低频访问，清明前后是脉冲式爆发。针对这个特征，我一般会在后端加三层缓存。第一层是纪念馆详情页的 Redis 缓存，key 用memorial:info:{id}，缓存时间 10 分钟，数据变更时主动失效；第二层是祭祀记录列表的 CDN 缓存，因为列表页面向公众，内容更新频率低，CDN 缓存 60 秒就够了；第三层是热门纪念馆的本地缓存，用 Caffeine 在 JVM 内缓存 top 100 的纪念馆信息，本地命中后连 Redis 都省了。三层命中下来，单个纪念馆详情页的接口响应能做到 20ms 以内。

数据归档是第二个必须做的点。祭祀记录表只保留最近一年的数据，更老的数据按月分表，比如worship_record_202503这种月表。查询的时候优先查月表，整个季度翻页查询走分区索引。归档任务用@Scheduled每天凌晨 3 点执行，先迁移再删原表数据，这个顺序不能反，否则归档失败的时候老数据已经没了。每次归档完成写一个日志文件，方便出问题时回溯。

清明前一周，我会把整条链路压测一遍。压测清单固定包含四件事：用 wrk 打纪念馆详情接口看 Redis 缓存命中率，用 jmeter 灌祭祀记录看 Redis 队列积压速度，观察 MySQL 慢查询日志有没有新的SELECT COUNT出现，最后审查一遍日志级别——把 debug 日志全关掉，改 info，否则清明高峰时日志磁盘会先爆。这套做法跑下来，基本能覆盖这个业务 80% 的坑。做这类后端，我的经验是：一定要把缓存失效、归档顺序、限流兜底这三件事写成运维手册，否则清明当天一紧张，全靠临时救火。希望帮到你。

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