企业官网建设流程全解析

1. 项目整体设计与技术选型思路

1.1 项目定位与核心需求拆解

做文化旅游类小程序，和做普通商城、工具类小程序最大的区别在于：它既要有内容展示的丰富性，又要兼顾图文、语音导览、票务预约这类强交互功能的稳定性。我拿到这个“基于SpringBoot的文化旅游小程序”需求时，第一反应不是急着写代码，而是先把“文化旅游”这四个字拆开看——文化和旅游，本质上是两个维度的融合。

文化侧，需要的是非遗展示、文物介绍、文化活动、历史典故这类内容型功能，特点是数据结构复杂、图文富文本居多、分类层级深。旅游侧，则需要景点导览、地图定位、语音讲解、门票预约、周边推荐这类服务型功能，特点是实时性要求高、和第三方系统交互频繁。两者放在一个小程序里，后端架构就不能简单搞一套CRUD了事，要考虑内容的动态配置、接口的灵活扩展、还有高并发场景下的性能兜底。

SpringBoot作为该项目的后端主体框架，最大的优势恰恰就体现在这里。它的自动装配机制让我们可以从容面对不同类型的模块接入，比如整合MyBatis-Plus做ORM映射、整合Redis做缓存热点数据、整合阿里云OSS做图片和视频的存储，每个模块都是独立接入，互不干扰。我第一次搭建项目骨架时，就把模块边界切清楚：内容发布系统、票务预约系统、导览服务系统、用户中心系统，四个核心模块相互独立又能协同，后续维护成本低很多。

1.2 为什么选SpringBoot + 微信小程序这套组合

先说前端为什么选微信小程序而不是原生App或H5。文化旅游场景有个天然特点：用户是“到了景区才想起来打开”，属于典型的低频但刚需场景，微信小程序“扫一扫即可使用、用完即走”的体验完全契合这种行为模式。再就是微信生态内的分享裂变能力，用户看到一个好玩的非遗展览，直接转发给朋友，整个传播链条零成本，这对文旅项目的拉新非常关键。

而后端选择SpringBoot，除了Java生态本身稳定之外，更务实的考量是招人好招、出问题好排查。文旅项目的甲方通常是文旅局、景区管委会这类机构，他们后续更关注系统的可持续运维能力，而不是技术栈有多新。SpringBoot加MyBatis-Plus这套组合，市面上学习资料多，外包团队接手快，踩坑率低，这一点在做技术选型时权重极高。

另外我特意在项目中预留了uni-app的兼容空间。虽然第一版交付的是微信小程序原生代码，但页面结构和API调用层做了隔离，后期如果需要迁移到支付宝小程序或抖音小程序，改动量可以控制在15%以内。这一步决策被很多同行忽略，但对文旅项目来说，多端投放其实是常态需求。

1.3 项目目录结构与工程规范

整个项目采用标准的Maven多模块结构，虽然目前是单体应用，但模块拆分从一开始就按微服务的边界来设计：

cultural-tourism/ ├── pom.xml # 父POM，统一依赖管理 ├── ct-admin/ # 后台管理端接口模块 ├── ct-api/ # 小程序端接口模块 ├── ct-common/ # 公共工具类、统一返回封装 ├── ct-framework/ # 框架配置层（安全、拦截器、全局异常） ├── ct-module-system/ # 系统管理模块（用户、角色、菜单） ├── ct-module-content/ # 内容管理模块（非遗、文物、活动） ├── ct-module-ticket/ # 票务预约模块 ├── ct-module-guide/ # 导览服务模块 └── ct-generator/ # 代码生成器模块

每个模块的依赖关系严格控制为单向依赖：api层依赖common和framework，模块层依赖common，模块之间不直接依赖。这个设计让我在实际开发中少吃了很多亏——最典型的就是ct-module-ticket需要读取内容模块的景点信息时，直接调用的是ct-api层的feign接口或者抽取shared包，而不是让module之间强耦合。

有一点值得特别提醒：pom.xml里的父依赖版本号我统一用了SpringBoot 2.7.x，而不是追最新的3.x。原因也很实际，2.7.x在第三方库兼容性上最稳定，比如微信小程序登录用的redis存储token、阿里云OSS的SDK，在2.7.x下都是全兼容状态，不用额外做适配。做文旅项目最怕的不是功能做不完，而是基础依赖跑着跑着莫名报错，这种隐性成本太高。

2. 核心功能模块与源代码解析

2.1 用户登录与手机号授权流程

文旅小程序不需要用户注册账号这种重流程，真正跑起来用的是微信生态的静默登录加手机号授权方式。代码核心分为三步：前端调用wx.login获取code，后端用code换openid和session_key，再结合手机号授权接口绑定手机号。这里面的坑我踩过一次，特意重点说明。

小程序端org.springframework.web.bind.annotation的controller层代码长这样：

@RestController @RequestMapping("/api/auth") public class AuthController { @Resource private IAuthService authService; @PostMapping("/login") public R<String> login(@RequestBody WxLoginDTO dto) { // 微信登录，返回自定义token return R.ok(authService.wxLogin(dto.getCode())); } @PostMapping("/bindPhone") public R<Boolean> bindPhone(@RequestHeader("token") String token, @RequestBody PhoneBindDTO dto) { // 绑定手机号，用于票务通知等场景 return R.ok(authService.bindPhone(token, dto.getPhoneCode())); } }

wxLogin的核心实现在service层，流程是code换session、openid查询用户、不存在则新注册，最终生成JWT token。有一点必须提醒：wx.login的code有效期只有5分钟，而且一次使用后立即失效。前端如果在这个接口上做了重试逻辑，第二次一定会登录失败。我当时排查过一个线上问题，用户反馈偶尔登录失败，最后定位就是前端拦截器把登录请求重复提交了。针对这种情况，我在后端做了兜底：同一个code请求两次直接返回友好提示，前端收到后重新调wx.login。

再说手机号绑定。微信官方从基础库2.21.2起推荐用getPhoneNumber按钮式授权，返回的是动态令牌phoneCode，后端拿着phoneCode去调phonenumber.getPhoneNumber接口才能换到真实手机号。这个接口每日调用次数有限，所以我特意加了Redis缓存：同一个openid当天只允许绑定10次，防止恶意刷接口。

2.2 文化内容管理与富文本处理

文化类内容（比如非遗技艺介绍、文物详情）的特点就是图文混排多、格式复杂度高。我在这个项目里没有自研富文本编辑器，而是直接采用了轻量级方案：后端存储Markdown源文本，前端用towxml解析渲染。这套方案的好处是存储体积小、搜索友好，同时对小程序端兼容性极好。

内容表的核心结构如下：

CREATE TABLE ct_article ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(200) NOT NULL COMMENT '标题', cover_image_url VARCHAR(500) COMMENT '封面图', summary VARCHAR(500) COMMENT '摘要', content_md LONGTEXT COMMENT 'Markdown内容', content_html LONGTEXT COMMENT '渲染后的HTML，冗余存储', category_id BIGINT COMMENT '所属类目', view_count INT DEFAULT 0 COMMENT '浏览量', status TINYINT DEFAULT 1 COMMENT '1-发布 0-草稿', create_time DATETIME, update_time DATETIME ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='文化内容表';

内容发布的管理端，我用的是定时任务加审核双机制。运营人员录入内容后先进入草稿状态，审核通过后定时任务自动发布。这个设计对文旅场景特别实用：景区经常有临时活动，比如“周六非遗市集”，运营可以提前录入好，设定周五晚上6点自动上线，不需要人工盯点去点发布按钮。

浏览量统计这里我做了个优化。没有采用简单的update view_count = view_count + 1，而是先写Redis的Hash结构，key为article:view:{id}，value累加计数，然后通过定时任务每5分钟批量同步到MySQL。高峰期文化专题页的流量可以到每秒几十次，直接怼MySQL数据库压力不小，走Redis中转后数据库qps直接降了一个量级。

2.3 景点导览与地图定位实现

景区导览模块是小程序里最体现“文旅特色”的功能。我用的是腾讯地图微信小程序JavaScript SDK，实现了景区内景点的列表展示、地图标注、路线规划三个核心能力。

地图相关的核心配置代码：

// app.js中初始化 const ttMap = require('./utils/qqmap-wx-jssdk.min.js'); App({ onLaunch() { this.globalData.qqmapsdk = new ttMap({ key: '你的腾讯地图Key' }); } });

景点列表页调用逆地址解析接口，把每个景点的经纬度转换成可读的地址描述：

// 景点详情页获取周边信息 const sdk = app.globalData.qqmapsdk; sdk.reverseGeocoder({ location: `${latitude},${longitude}`, success(res) { // 获取周边POI信息 const pois = res.result.pois; this.setData({ nearbyPois: pois.slice(0, 5) }); } });

这里有一个很容易被忽略的问题：腾讯地图SDK的key必须配置域名白名单，而且小程序的request合法域名里必须加上https://apis.map.qq.com。很多同学第一次调试时发现地图接口调不通，八成是这两个地方漏了。

导览的语音讲解功能，我采用的是音频文件预加载加缓存策略。小程序端在用户进入景区WiFi区域后预热下载当前景点区域的音频包，这样用户在游览到具体点位时，点击播放可以即时响应，不需要现场等网络加载。音频文件存OSS，通过CDN加速分发，实测在弱网环境下也能在200ms内完成起播。

2.4 票务预约与订单状态机设计

票务预约是文旅小程序的重头戏，也是业务逻辑最复杂、坑最多的模块。核心是下单、支付、核销、退款四个环节，我重点说一下状态机的设计。

订单表中状态字段我用的是status，0待支付、1已支付待使用、2已使用、3已退款、4已取消、5退款中。为了避免多个请求同时修改订单状态导致数据错乱，我引入了Redis分布式锁：

public boolean lockTicket(Long orderId, Long userId) { String lockKey = "ticket:lock:" + orderId; String lockValue = String.valueOf(userId); Boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, lockValue, 30, TimeUnit.SECONDS); return locked != null && locked; }

锁过期时间设30秒，但业务操作通常1秒内就能完成，所以锁基本不会误伤正常请求。一旦获取锁失败，说明有人正在操作这单，直接提示“系统繁忙，请稍后再试”，性能损耗可以忽略不计。

订单超时取消是另一个典型问题。用户下单但没支付，需要延迟关闭订单释放库存。我用的延迟队列方案：下单时把订单ID丢进Redis的ZSet，score为“创建时间+30分钟”的时间戳，起一个定时任务每30秒扫描一次，把超时且未支付的订单标记为取消并回补库存。

// 延迟队列：下单后加入 String key = "order:delay:cancel"; redisTemplate.opsForZSet().add(key, orderId.toString(), System.currentTimeMillis() + 30 * 60 * 1000); // 定时任务扫描 public void scanTimeoutOrders() { String key = "order:delay:cancel"; long endTime = System.currentTimeMillis(); Set<String> timeoutOrders = redisTemplate.opsForZSet() .rangeByScore(key, 0, endTime, 0, 100); for (String orderIdStr : timeoutOrders) { // 执行关闭订单逻辑 closeTimeoutOrder(Long.valueOf(orderIdStr)); // 移除已处理订单 redisTemplate.opsForZSet().remove(key, orderIdStr); } }

退款环节对接的是微信支付V3接口。有一点值得提，微信支付V3的证书和密钥处理比V2复杂，我经历了多轮调试才完全跑通。关键是要在application.yml中正确配置商户号和APIv3密钥，同时证书会用wechatpay-apache-httpclient的工具类来加载。签名生成的报文调试时一定要用微信官方提供的在线调试工具比对一次，不然两张证书来回切换很容易懵。

3. 部署环境准备与全流程操作指南

3.1 服务器选型与基础环境初始化

文化旅游小程序的并发量通常有明显的波峰波谷：工作日可能只有几十人在线，节假日尤其是“五一”“国庆”这种黄金周，瞬时流量可能翻几十倍。基于这个特点，我选择的部署方案是：2核4G云服务器起步，数据库单独部署在另一台机器，Redis使用云服务商提供的托管实例。

服务器操作系统选的是CentOS 7.9（如果你用新购服务器，选Alibaba Cloud Linux 3也可，命令基本兼容）。环境初始化用脚本批量处理，避免人工一步步安装出错：

# 安装JDK 8+（这里安装的是OpenJDK 1.8） yum install -y java-1.8.0-openjdk-devel # 安装Nginx（做反向代理和静态资源服务） yum install -y nginx # 安装MySQL 5.7 yum install -y mysql-community-server # 安装Git yum install -y git

验证环境是否装好的命令很简单：

java -version nginx -v mysql --version git --version

这里有个细节容易踩坑：服务器安全组必须放通80、443端口，以及后端服务自定义的8080端口。我原来部署时只开通了80端口，结果前端小程序访问后端接口一直超时，排查了小半天才想起来8080端口在云控制台的安全组里没有配置入方向规则。所以第一次部署一定要记得检查安全组和防火墙规则。

3.2 MySQL数据库初始化与导入

拿到项目的源码包后，数据库脚本一般在sql/目录下保存为.sql文件。导入数据前，先建库，因为脚本内容多数情况下是按数据库维度导出的：

mysql -uroot -p > CREATE DATABASE cultural_tourism DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; > USE cultural_tourism; > SOURCE /path/to/cultural_tourism.sql;

导入数据时屏幕上会滚动很多SQL执行日志，不用慌，等出现Query OK和Query OK连续的输出，再有最后一行mysql>重新出现，说明导入完成。为了验证数据是否导入成功，可以执行：

USE cultural_tourism; SHOW TABLES; SELECT COUNT(*) FROM ct_article;

建议：导入数据之前先看一眼SQL文件里的表名前缀和建库语句是否包含CREATE DATABASE。很多外包项目交付的是全量脚本，包含建库语句，这时你直接SOURCE导入会出现“Can‘t create database”提示或者覆盖同名库，一定要核对清楚。如果脚本里已经有USE xxx，那你手动创建的库名必须和脚本里一致，否则所有表都建到了别的库下。

3.3 后端服务配置与打包部署

拿到源码后用IDE打开，先改配置文件application-prod.yml，这里要改的地方最集中，也是最容易出错的地方：

server: port: 8080 spring: datasource: url: jdbc:mysql://你的数据库IP:3306/cultural_tourism?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: your_username password: your_password redis: host: 你的Redis实例IP port: 6379 password: your_redis_password database: 0 wx: mini-program: app-id: 你的小程序AppID app-secret: 你的小程序AppSecret aliyun: oss: endpoint: oss-cn-hangzhou.aliyuncs.com access-key-id: your_key access-key-secret: your_secret bucket-name: your_bucket

改完配置后，用Maven跳过测试打包：

mvn clean package -DskipTests

打包完成后在ct-admin/target/目录下找到ct-admin.jar，上传到服务器。推荐用scp命令或宝塔面板的文件上传功能，直接上传到/opt/cultural-tourism/目录。启动服务：

nohup java -jar /opt/cultural-tourism/ct-admin.jar \ --spring.profiles.active=prod \ --server.port=8080 \ > /opt/cultural-tourism/logs/ct-admin.log 2>&1 &

启动完看日志确认有没有报错：

tail -f /opt/cultural-tourism/logs/ct-admin.log

日志中出现Started Application in x.xx seconds就说明启动成功了。

3.4 Nginx反向代理与HTTPS配置

后端服务起来了，还需要Nginx做反向代理，把https://api.yourdomain.com转发到服务器的8080端口。为什么需要这一步？因为小程序端request的域名必须是HTTPS，而且域名必须在微信公众平台后台配置到request合法域名列表里。

Nginx配置核心片段：

server { listen 80; server_name api.yourdomain.com; return 301 https://$host$request_uri; } server { listen 443 ssl; server_name api.yourdomain.com; ssl_certificate /etc/nginx/ssl/yourdomain.pem; ssl_certificate_key /etc/nginx/ssl/yourdomain.key; location / { 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-For $proxy_add_x_forwarded_for; } }

修改完Nginx配置后，用nginx -t测试配置正确性，然后systemctl reload nginx让配置生效。

HTTPS证书我用的免费的单域名证书，阿里云或腾讯云控制台都能申请，一年有效期，到期前会收到短信提醒，记得提前续期。有一个隐蔽问题：如果服务器上有多个小程序或业务共用同一个IP，SSL证书配置不能有冲突，否则会把其他业务的HTTPS也搞挂。

3.5 微信小程序前端导入与发布流程

前端代码是微信小程序原生工程，直接用微信开发者工具打开。导入工程的步骤是：打开微信开发者工具 -> 项目 -> 导入项目 -> 选择mini-program/目录 -> 填写AppID -> 确定。

导入后第一件事不是预览，而是修改接口请求基础路径。在config/api.js文件里：

module.exports = { // 开发环境 baseUrl: 'https://api.yourdomain.com', // 本地联调时可以切成这个 // baseUrl: 'http://127.0.0.1:8080' };

本地联调时还有一个关键配置：在微信开发者工具的“详情 -> 本地设置”里勾选“不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书”。这样才能在开发阶段直接请求本地后端服务，但真机预览时要把这个勾选去掉，否则正式环境会请求失败。

发布上线流程是：工具右上角“上传”按钮 -> 填写版本号和备注 -> 在微信公众平台后台的“版本管理”中找到开发版本 -> 提交审核 -> 审核通过后点“发布”。一般来说文旅类小程序审核相对宽松，只要不涉及特殊行业资质，1到3天就能过审。

4. 常见问题清单与排查思路实录

4.1 小程序白屏与接口超时问题

现象：小程序页面能打开，但列表数据加载不出来，控制台显示网络错误或超时。

排查步骤：

1. 用开发者工具Network面板看请求的接口状态码，是404、500还是超时。
2. 404情况一般是接口路径或Nginx代理配置错误，检查nginx配置转发路径和后端controller的RequestMapping是否一致。
3. 500情况大概率是后端运行报错，直接翻后端日志，常见的有数据库连接断开、空指针、SQL语法错误。
4. 超时情况优先检查服务端到数据库或Redis的网络连通性，用telnet 数据库IP 3306测试端口是否通。

实战案例：有次用户反馈分类页白屏，我排查后发现是接口报500错误，日志显示MySQL死锁。原因是同一时间多个用户同时创建订单，InnoDB的锁竞争比较激烈。优化方案其实不复杂：把下单的事务里不必要的查询移出去，事务范围只保留insert和update操作，死锁概率直接降为零。

4.2 验证码收不到或登录态丢失

现象：用户反馈手机验证码一直收不到，或者登录后过一会儿又让重新登录。

排查逻辑：验证码收不到，优先看短信服务商的控制台是否有发送记录。我项目里用的是阿里云短信，在控制台能看到每条短信的发送状态和回执信息。如果显示发送成功但用户收不到，90%是短信模板内容不符合运营商审核规范，比如模板里带了“验证码”三个字容易被拦截，建议改成“校验码”或者“动态密码”。

登录态丢失通常和token有效期设置有关。我项目里JWT token默认有效期是7天，小程序端会把token存储到Storage里。如果你发现用户频繁重新登录，排查两个地方：一是后端token过期时间是不是被改短了；二是服务器时间是否和真实时间一致。服务器时间偏移超过几分钟就会导致JWT的exp验证不通过，这个坑是我亲身踩过的，服务器时间飘了十分钟，全站用户登录态全失效。

4.3 地图接口在正式环境调用失败

现象：本地开发环境地图显示正常，上传体验版或正式版后地图空白或报错。

原因：正式环境中request合法域名没有添加腾讯地图API域名。在微信公众平台后台 -> 开发管理 -> 开发设置 -> 服务器域名，把https://apis.map.qq.com加入request合法域名列表。

另一个原因可能是腾讯地图key开启了域名白名单限制，需要在小程序后台把域名加进去。

4.4 支付回调不生效与金额单位问题

现象：用户支付成功，但订单状态一直是待支付。

排查过程：微信支付成功后，微信服务器会异步回调你配置的notify_url。如果回调地址不可访问或者响应格式不对，微信会尝试多次回调，最终放弃。排查看三点：

1. 回调地址是否公网可访问，不能用localhost或内网IP。
2. 回调接口是否返回了正确的XML格式<xml><return_code><![CDATA[SUCCESS]]></return_code><return_msg><![CDATA[OK]]></return_msg></xml>。
3. 是否处理了重复回调的问题，接口要做幂等处理，保证同一笔订单多次回调结果一致。

金额单位的问题这里要重点提醒：微信支付接口中的金额单位是“分”，你数据库里如果存的是“元”，入库前必须乘以100。我当时有个订单金额是88.5元，由于没做单位换算，数据库里存成了88.5分，核销时对不上账，排查了大半天。建议订单金额字段直接改用DECIMAL(10,2)存元，调微信接口时再乘100。

4.5 定时任务不执行

现象：订单超时关闭、内容定时发布的定时任务完全不触发。

排查思路：先看SpringBoot应用启动类上有没有加@EnableScheduling注解，这个漏掉是最常见原因。再看定时任务类上有没有加@Component注解。最后确认application.yml中没有把scheduling的相关配置关掉。定时任务的执行时间最好避开整点集中触发，比如超时扫描任务我设在每分钟的15秒执行，而不是整点，避免和整点的数据备份任务冲突。

5. 代码讲解方法建议与二次开发指引

5.1 怎么高效看懂这套源码

很多朋友拿到源码后习惯从头文件一个个挨着读，效率极低。我建议按业务链路来读，比如你想弄懂“用户登录到购买门票”这条主链路：

• 先看小程序前端pages/index/index.js调用哪个接口
• 再去看controller层的对应方法
• controller调用哪个service
• service里调用了哪些mapper
• mapper对应的SQL是什么

按照这个链路去读，比泛泛而读效率高非常多。

源码包一般会附带设计文档和数据库ER图，先花半小时浏览一遍文档再上手读代码，事半功倍。如果文档不全，直接看数据库表结构也基本能反推出业务逻辑，比如看到order_status字段的注释写的是“0待支付 1已支付”，那你的核心状态流转就清楚了。

5.2 项目二次开发的热门方向

做了这么多文化和旅游类的项目，我总结出几个甲方的扩需方向，你可以参考：

一是多语言版本支持。很多文旅项目会面向外国游客，小程序加一个英文/日文切换，界面文案单独抽成i18n资源文件即可，后端不用大改。

二是智能推荐系统。根据用户的浏览记录、预约历史，推荐相似的活动或景点。刚起步不需要上复杂的推荐算法，用协同过滤的思路，基于用户所处地域和浏览行为做简单标签匹配就能见效。

三是数字人导览或AR识别导览。这是目前文化展馆和景区的热门投入方向，虽然对服务器性能和前端能力要求更高，但一旦做出来，体验感和传播力完全不一样。

四是与当地文旅局数据平台对接。地方文旅局往往有“一部手机游xx”的省级平台，如果项目需要对接，后端要预留标准数据接口。我在做这个项目时就在导出/api/v1/statistics/visit接口，就是为了便于后续对接大数据监管平台。

5.3 项目的性能优化空间

文旅项目上线后，性能调优还有不少提升空间。排查热点接口的SQL执行计划，看索引有没有命中，是最直接的优化手段。举例来说，内容文章列表页如果没做分页缓存，高峰期查询可能需要500ms以上，加了Redis缓存后，接口响应能降到50ms以内。

高频查询的景点信息、轮播图、公告类内容，都适合做缓存。可以采用Cache Aside Pattern，读的时候先查缓存，命不中再查数据库并写回缓存；更新的时候先更新数据库再删除缓存。这套模式虽然老，但应付文旅项目的访问量绰绰有余。

6. 我一直保留的几个实操习惯

6.1 上线前必做清单

我每次给客户交付文旅小程序项目，上线前一晚都会按清单走一遍：

• 后端接口全部用Postman或Apifox跑一遍，重点测登录、下单、支付回调三条主链路。
• 小程序体验版真机测试，覆盖iOS和Android各一台，至少过一遍完整的“浏览景点 -> 预约门票 -> 支付 -> 订单页查看”的流程。
• 检查Nginx是否开启了HTTPS并正确跳转，所有静态资源走HTTPS。
• 检查数据库自动备份任务已配置，至少保留最近7天的备份。
• 检查服务器防火墙，高危端口（22、3306、6379）是否限制只允许特定IP访问。
• 确认mysql和redis的连接池配置合理，不至于在高并发时被打满。

6.2 日志规范与线上问题追踪技巧

日志记录真的建议从一开始就规范化。我的做法是logback配置里按“系统模块-操作类型”分目录输出，比如content-error.log、ticket-error.log、auth-error.log，这样线上出问题，tail -f对应模块的日志文件就能精准定位。

补充一个建议：在关键业务节点打印日志时带上可追踪的traceId。比如下单操作，从controller到service再到mapper全程打同一个加订单号标记的日志，后面排查问题可以直接按订单号搜索整个链路。这个改动看着小，但实际排查问题的效率能提升好几倍。

6.3 源码文档的管理心得

交付源码时文档组织不能乱。我在每个项目交付时都会整理好三层文档：部署文档、开发文档、使用文档。部署文档给运维或客户技术看，写清楚服务器要求、环境变量配置、启动命令；开发文档给接手开发的程序员看，说明模块结构、核心流程、二次开发注意事项；使用文档给运营人员看，侧重于管理后台如何录入内容、查看订单这类操作。

文档格式我统一用Markdown，存到项目gitee或代码托管平台的wiki里，方便客户随时查阅更新。配几张关键流程图（比如订单状态流转图、用户登录时序图）会让文档直观很多，比大段文字更容易理解。

最后说一点心得。SpringBoot文旅小程序的源码和部署文档，网上确实能搜到不少，但绝大多数是简单的CRUD堆积，真正能扛住线上流量、处理好文旅业务复杂性的项目还是需要自己梳理清楚。我每次做这类项目都在提醒自己：技术栈只是工具，核心是把文化和旅游的业务逻辑摸透，用最稳妥的方案落地。希望这篇记录能给正在做文旅项目的朋友一些实质性的参考。