做摄影交流平台这件事听起来是个标准需求但真拆开之后会发现它是一个“内容社区 工具型小程序”的混合体。摄影和普通的晒图不一样用户对画质、构图、参数和话题有着强诉求。你看一个摄影博主发的照片评论区通常充斥着“求参数”“什么镜头拍的”“光圈开到多大”所以平台不只是存图片、展示图片那么简单它还得把 EXIF 信息、拍摄场景、器材标签、主题分类这些维度管理起来。我用 Spring Boot 做后端微信小程序做前端核心就是为了把两条链路打通。一条是内容链路用户拍照上传、系统存储处理、动态分发到信息流另一条是互动链路点赞评论、关注取关、消息通知。这两个链路几乎覆盖了平台 80% 的功能点也是大多数内容类小程序的基本盘。如果你正准备做毕业设计或者想给自己攒一个能上线的摄影社区原型这套设计可以当模板直接用。1. 项目定位与整体思路它到底要解决什么问题1.1 从标题拆解平台的三个核心模块你把这个标题拆开看“springboot基于微信小程序的摄影交流平台”关键词有三个springboot、微信小程序、摄影交流。前两个是技术载体真正决定产品形态的是“摄影交流”。交流不是发个动态那么简单。摄影圈子里的交流深度远高于普通社交平台一张照片背后有器材信息、拍摄参数、后期思路、取景地点。所以我在设计功能时没有照着“小红书”那种泛图文社区抄而是把摄影人真正需要的素材拆成了三块内容模块作品发布、图片九宫格/单图上传、标签系统题材、机位、器材、后期、作品详情的 EXIF 展示。互动模块点赞、收藏、评论、关注、私信、话题挑战、月度榜单。用户模块微信一键登录、个人主页、作品集展示、关注粉丝列表、消息通知中心。这三个模块互相咬合。内容模块负责产生数据互动模块产生数据间的关联用户模块串联所有关系的归属。后端所有表设计都是围绕这三条线展开的。我在最开始就画了一张粗颗粒度的表关系图用户表、作品表、标签表、关注表、点赞表、评论表、消息表、话题表。看似多实际上每张表都只有五六个核心字段因为摄影交流本质上就是“用户–作品–互动”的三角关系。1.2 为什么一定是 Spring Boot 微信小程序而不是别的组合很多人纠结技术选型其实这个组合是被场景逼出来的。小程序端不用多说摄影交流平台的用户场景就是“看到好风景随手拍随手传随手刷”。微信小程序免安装、打开即用、微信授权登录天然打通社交流量对内容社区来说这是最顺滑的分发入口。对比一下安卓/iOS 原生 App开发周期长、上架审核复杂、推广成本高对比 H5 页面又没有原生相册流畅的选图体验和下拉刷新手感。小程序处在中间位开发效率高到达率也高。后端用 Spring Boot 是综合考量。作为一个要处理图片存储、点赞计数、信息流排序、用户关系链的项目需要稳定的 ORM 框架、成熟的生态和足够多的现成方案。Spring Boot 在这块有天然优势集成 MyBatis-Plus 简单做 JWT 鉴权有 Spring Security/自写拦截器两条路文件存储对接 MinIO 有现成 SDK部署到服务器用 Docker 也很顺。如果换成 SSM 手搓配置光 XML 就能写几百行换成 Go 或 Node 也不是不行但招聘理解成本、毕业设计答辩的成熟度、后续维护资料量都不如 Spring Boot 让人省心。1.3 MVP 功能清单哪些功能先做哪些坚决不做我给自己定的 MVP 范围很简单能注册、能发图、能刷列表、能评论点赞、能关注。先把这些做扎实再谈别的。下面是功能清单我按“是否纳入第一期开发”做了个划分模块功能点MVP是否包含备注用户微信登录、个人资料编辑是头像、昵称、简介用户关注/取关、粉丝列表是关系表单建作品图片发布、删除是支持多图存图片 URL作品EXIF 信息展示否需要后端解析二期再上作品视频上传否流量和存储成本高等用户量起来再说互动点赞、取消点赞是用 Redis 做计数互动评论、删除评论是支持楼中楼互动收藏、收藏夹是和点赞分开内容流最新列表、热门列表是时间排序 热度加权内容流关注动态流是用 Redis 拉取或数据库查询话题话题挑战、月度榜单否第二期运营功能这个 MVP 规模一个人全职做大概 20 到 25 天能完成前后端联调。我实际做的时候小程序部分用了 8 天后端用了 12 天剩余时间全部花在真机调试和修 bug 上。2. 后端篇Spring Boot 项目的骨架怎么搭2.1 项目初始化和版本选型后端工程我建议直接用 Spring Initializr 生成别自己手搭 Gradle 目录了效率太低。版本上有两个派系Spring Boot 2.7.x JDK 8或者 Spring Boot 3.x JDK 17。我这次用的是 Spring Boot 2.7.12 JDK 8。原因很现实大多数学校服务器、学生本机环境还是 JDK 8数据库驱动、第三方 SDK 的兼容性也最省心。如果你的机子是 M 系列 Mac 且只做学习验证直接上 3.2 JDK 17 也没问题但要注意 MyBatis-Plus 要选 3.5.5 版本才适配 Spring Boot 3。依赖管理上最核心的是这几项dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependency dependency groupIdio.minio/groupId artifactIdminio/artifactId version8.5.7/version /dependency我踩过一个坑jjwt 0.9.1 在高版本 JDK 上会报JCE cannot authenticate the provider BC因为它默认依赖的 JAXB 被移除了。解决办法是额外引入javax.xml.bind:jaxb-api:2.3.1或者在 JDK 8 环境跑别在 JDK 17 上硬调。2.2 目录结构和统一接口设计后端目录我习惯按功能分包而不是按技术层分包。很多教程喜欢controller/service/mapper/entity这样建包我试过一旦功能多了就乱套。比如用户相关的控制层、服务层、实体全挤在一起想找作品相关代码得来回切。我推荐按模块分包com.example.photoforum ├── common # 统一返回、异常、工具类 ├── config # 配置类MinIO、拦截器、分页插件 ├── module │ ├── user # 用户模块controller/service/mapper/entity/dto │ ├── work # 作品模块 │ ├── interact # 点赞评论关注模块 │ └── message # 消息模块 └── security # JWT 拦截器这种结构在 IDEA 里导航特别舒服代码量大了之后也不会迷路。统一接口返回是个老生常谈但要落到实处。我定义了一个ResultT包含code/message/data三个字段。所有 controller 直接返回Result.success(data)或Result.error(参数错误)。同时配了一个全局异常处理器用RestControllerAdvice捕获业务异常和兜底异常。这两个东西的价值等到你被NullPointerException和“小程序端莫名白屏”折磨的时候就会懂。没有统一返回小程序端每个请求都得做一层差异化解析很容易解析出错。2.3 微信登录鉴权wx.login JWT别用麻烦的 session小程序的登录链路和普通网页登录不一样。用户不需要输账号密码前端调wx.login()拿到一个临时 code传给后端后端拿着 code appid secret 去微信接口换openid。openid 就是用户在微信生态内的唯一身份。后端拿到 openid 之后去用户表查有没有这个用户没有就新建一条有就更新登录时间然后签发一个 JWT 返回给小程序。小程序把 token 存到wx.setStorageSync里之后所有请求在 header 带Authorization: Bearer token。签发 JWT 的核心代码很短但要设置合理的过期时间。我这个项目设的是 7 天对于摄影分享这种低频高频混合的社区来说太够了。过期后用刷新 token 或重新登录都行为了省事我直接选了重新走 wx.login反正微信登录对用户无感。public String createToken(Long userId) { long now System.currentTimeMillis(); return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(loginTime, now) .setExpiration(new Date(now 7 * 24 * 3600 * 1000L)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); }这里有一个很难发现的坑如果用jjwt 0.9.1的parseClaimsJws解析 tokenHS256 的密钥长度至少得 32 字节短了会抛WeakKeyException。网上很多例子写的是secret这种短密钥跑 Demo 没问题放到这个项目里就挂。别问我是怎么知道的。2.4 作品上传MinIO 接入与图片压缩摄影平台的图片文件是核心资产上传功能必须好好设计。我第一版用过本地路径存储服务器磁盘写文件数据库存路径。后来发现横向扩容太麻烦换了 MinIO。MinIO 是一个兼容 S3 协议的对象存储服务简单说就是搭建一个私有云盘用 API 读写文件。它支持分布式部署也支持 Docker 一键启动接入 Spring Boot 有官方 SDK。我的配置放在 application.ymlminio: endpoint: http://你的服务器IP:9000 access-key: minioadmin secret-key: minioadmin bucket-name: photo-works上传工具类的核心逻辑分三步校验 bucket 是否存在不存在就创建生成唯一文件名UUID 后缀上传并返回访问 URL。public String upload(MultipartFile file) throws Exception { String originalFilename file.getOriginalFilename(); String suffix originalFilename.substring(originalFilename.lastIndexOf(.)); String objectName UUID.randomUUID().toString().replace(-, ) suffix; boolean exist minioClient.bucketExists(BucketExistsArgs.builder().bucket(bucketName).build()); if (!exist) { minioClient.makeBucket(MakeBucketArgs.builder().bucket(bucketName).build()); } minioClient.putObject(PutObjectArgs.builder() .bucket(bucketName) .object(objectName) .stream(file.getInputStream(), file.getSize(), -1) .contentType(file.getContentType()) .build()); return endpoint / bucketName / objectName; }我强烈建议在后端做一层图片压缩。手机拍出来的原图动辄 4~8MB不压缩的话用户上传一次消耗流量不说列表页加载 20 张图直接卡成 PPT。我用 Thumbnailator 做压缩超过 2000px 的长边就缩到 2000px质量参数设为 0.85肉眼基本看不出画质损失体积能小一半以上。图片一律不存数据库数据库只存 URL 字符串。查询的时候如果有压缩版和原图版就存两个 URL 字段列表页用压缩版缩略图详情页用原图。2.5 列表分页MyBatis-Plus 分页插件怎么配最省心摄影交流平台的信息流是典型的列表分页场景。翻页方式我选的是“游标 偏移”混合策略首页加载用LIMIT 0,10后面翻页为了性能优先用WHERE id 上一页最后一条ID ORDER BY id DESC LIMIT 10。这种基于游标的方式在数据量大了之后不会因为深度分页变慢。但如果用 MyBatis-Plus很多人第一反应是用Page对象。这个可以但有个细节要注意必须在配置类里注册 PaginationInnerInterceptor否则page查出来的数据永远是全量。Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }列表排序不能只按时间。纯按时间的话热门作品和新作品混在一起用户刷两屏就没兴趣了。我做了一个简单热度公式热度分 点赞数 * 1 评论数 * 2 收藏数 * 3再乘以一个时间衰减系数。落地方式就是在 SQL 里算一个score字段ORDER BY (like_count * 1 comment_count * 2 favorite_count * 3) / POW(1 TIMESTAMPDIFF(HOUR, create_time, NOW()) / 24, 1.5) DESC这个公式保留了热门度的优势又不至于让三个月前的爆款一直压着新作品。要更精细的话把指数换成可配置参数就行。3. 小程序端摄影交流场景怎么落地3.1 原生小程序还是 uniapp我选了原生搜索这个项目的时候你一定看过 uniapp vs 原生小程序的讨论。我的意见是如果项目只有微信小程序一个端别折腾 uniapp直接用原生。uniapp 最大的价值是“一套代码多端复用”但代价是兼容性调试成本。你写了 Vue 语法最终还要转成小程序渲染遇到 API 差异还得写条件编译。在摄影交流这种需要深度使用相册选择、图片上传、地图定位的场景原生 API 最直接文档也最全。我自己开发的时候只用原生真机一跑就通不用考虑跨端的“理论上兼容”。不过如果你是拿这个项目找工作面板上写“uniapp”会增加一些市场宽度。这个看个人取舍我不硬推。3.2 页面结构五个 Tab加一个隐藏发布页小程序端采用 TabBar 体系。底部五个入口加上一个中间“发布”按钮的“网红布局”已经烂大街了我这次没搞中间凸起按钮直接五个标准 Tab首页、发现、消息、我的再加一个“”发布。发布页不走 TabBar 路由而是用wx.navigateTo跳转到独立页面。为什么因为 TabBar 页面一旦注册就没有页面间的转场效果发布作为一个高频但非浏览性的动作独立页面更干净。首页是信息流用scroll-view做下拉刷新和触底加载。发现页是分类浏览顶部放标签筛选栏底部是月度榜单入口。我的页面就是个人作品集 关注列表。消息页就是评论、点赞、关注三类通知列表。页面结构定下来之后就是稳定的开发节奏。我一般是先搭骨架再用真实数据调样式。3.3 顶部导航栏高度为什么不能直接写死 44px小程序开发时顶部导航栏是绕不开的坑。iPhone 和 Android 机型的状态栏高度不同有刘海的设备安全区域也不同。很多人直接把导航栏写成height: 44px在 iPhone 14 上就会顶到状态栏看着特别业余。正确做法是用小程序提供的能力动态拿高度。系统胶囊按钮的位置可以帮我们精确计算const systemInfo wx.getWindowInfo ? wx.getWindowInfo() : wx.getSystemInfoSync(); const menuRect wx.getMenuButtonBoundingClientRect(); Page({ data: { statusBarHeight: systemInfo.statusBarHeight, navBarHeight: (menuRect.top - systemInfo.statusBarHeight) * 2 menuRect.height } })menuRect.top - statusBarHeight就是胶囊距离状态栏的间距乘以 2 再加胶囊自身高度得到的就是导航栏整体高度。这个值在每台真机上都是精确的。你只需要把这个值设置到导航栏容器的高度和内边距上适配就完成了。3.4 请求封装与 token 续期小程序端的请求封装算是个高频搜索词确实值得认真写。我封装了一个request.js核心做三件事统一 baseURL、统一 header 注入 token、统一错误处理。const request (url, method GET, data {}) { return new Promise((resolve, reject) { const token wx.getStorageSync(token) wx.request({ url: BASE_URL url, method, data, header: { Authorization: Bearer token }, success(res) { if (res.data.code 200) { resolve(res.data.data) } else if (res.data.code 401) { // token 失效重新登录 login().then(() request(url, method, data)).then(resolve).catch(reject) } else { wx.showToast({ title: res.data.message, icon: none }) reject(res.data) } }, fail(err) { wx.showToast({ title: 网络异常, icon: none }) reject(err) } }) }) }这里有个细节401 之后自动重新登录再请求但要注意避免死循环。我加了一个标志位isRefreshing同一时刻只有一个重登请求在跑其他请求先进入待处理队列重登完成后再统一放行。否则用户网络波动时十几个并发请求同时 401会触发十几轮重复登录接口被刷爆。3.5 图片选择、上传与预览摄影平台的小程序端选图 UI 要尽量接近相册体验。wx.chooseMedia是当前推荐的 API可以同时选图片和视频。wx.chooseMedia({ count: 9, mediaType: [image], sourceType: [album, camera], sizeType: [compressed], success: (res) { const files res.tempFiles.map(item item.tempFilePath) this.setData({ images: files }) } })上传的时候要注意小程序端的wx.uploadFile一次只能传一个文件多图要逐个传全部传完后拿到 URL 列表再调发布接口。我用Promise.all控制并发一次最多三个并发避免连接数满导致上传失败。一开始是全部一起传真机测试 9 张图的时候成功率只有六成改成并发 3 之后就稳定在九成以上。图片预览用wx.previewImage传一个当前索引和完整 URL 列表。这个 API 自带缩放、左右滑动、保存到相册比自己写弹窗省太多事。3.6 视频内容与缓存策略要不要做视频下载搜索词里“微信小程序中的视频下载”是高频我在开发时也考虑过摄影平台要不要支持视频上传用户能不能缓存视频到本地结论是MVP 阶段我不做视频下载。微信小程序天然不支持把网络视频直接存到本地相册除非用wx.downloadFile下载临时文件再配合用户授权保存到相册但受文件大小和格式限制很多。而且视频对服务器的带宽和存储压力是图片的好几倍个人开发者扛不住。我最终做的视频策略是允许上传和在线播放但限制时长不超过 60 秒文件大小不超过 20MB使用 HTTP Range 协议做分片加载播放页用video组件控制。在线播放用浏览器的缓存机制就够了不需要额外做本地持久化缓存。如果要更激进可以再叠加一个“仅 WIFI 下自动播放视频”的设置避免用户流量焦虑。这类细节虽然小但用户感知非常强。4. 硬骨头图片社区的性能与安全4.1 图片压缩与 CDN 缓存摄影平台是图片密集型服务性能瓶颈基本都集中在图片加载上。除了后端上传时压缩还要考虑列表页缩略图与详情页大图分离。我把图片 URL 设计成带参数的形式http://你的域名/photo-works/xxxx.jpg借助 Nginx 的 proxy_pass 和image_filter模块做实时裁剪。Nginx 配置一个/thumbnail路径返回指定宽度的图片。这样上传一套原图前端可以按需请求不同尺寸图片体感加载速度快很多。如果预算允许更建议接入 CDN。国内主流的云服务商都有对象存储 CDN 方案把图片访问域名直接切到 CDN源站指到 MinIO 或云对象存储。这一步优化做完后即使没有服务器性能调优列表页的加载速度都能提升一倍以上。4.2 缓存策略Redis 缓存热点数据共享、点赞、收藏这些数据都是高频读写。摄影平台初期用户量小直接查数据库没什么问题但为了给后面留余地我引入 Redis 做一层缓存。缓存分两层。第一层是对象缓存比如首页信息流的列表数据缓存 key 为feed:index:page:1过期时间 120 秒。第二层是计数缓存用 Redis 的INCR做点赞数和收藏数累加然后定期同步回数据库。我的实现思路是用户点赞成功后Redis 里work:detail:1024:likeCount加一同时记录异步任务每 5 分钟把 Redis 的计数值批量 update 到 MySQL。这样就算 Redis 挂了丢的也只是最近几分钟的计数增量主库数据还在。要注意的是缓存更新别用“更新后立即同步 MySQL”的方案点赞这种高频操作会让数据库 TPS 暴涨。异步批量才是最健康的做法。4.3 内容安全与 XSS 过滤搜索词里有一句“springboot项目全局过滤器处理上传pdf文件时xss攻击”放在摄影平台里同样适用。文字内容照样有 XSS 风险尤其是评论、个人简介、话题描述这些用户可控字段。如果用户在昵称里写入scriptalert(xss)/script其他用户加载列表时小程序端rich-text组件如果没做安全处理就可能执行脚本。我的做法是双重过滤。后端接收所有字符串参数时先经过一个全局过滤器把危险字符如、、javascript:等转义同时数据库字段设计时用业务层统一拦截二次清洗。实体层保存时用TableField定制字段类型评论内容长度限制 500 字符简介长度限制 100 字符从源头上限制恶意内容的空间。除了 XSS图片内容本身也要考虑安全。个人开发者没有能力人工逐张审核但至少可以接入微信官方的内容安全检测接口在用户上传图片时异步调用security.msgSecCheck做检测返回不合规时打标记后台再做处理。这一步不能省。4.4 接口幂等性与频控做内容社区最容易翻车的是并发场景下的数据错乱。举一个例子用户快速双击点赞前端发了两次请求后端如果没做幂等点赞表里就插入了两条记录再次点击取消赞时逻辑就乱了。我给点赞接口做的处理是点赞前查询是否存在记录存在则调用取消逻辑不存在则插入。同时前端按钮做 loading 防连点交互上彻底堵住重复提交。接口频控也要做。评论、点赞这些接口不能无限调用我自定义了一个基于 Redis 的限流注解RateLimiter限制每用户每分钟操作次数。配置在拦截器里通过 token 解析 user_id然后INCR EXPIRE实现滑动窗口。超出限流的请求直接返回“操作过于频繁”。这个限流逻辑不光保护数据库还防止了有人写脚本短时间内灌水刷评论内容质量也能保得住。5. 上线部署与日常维护5.1 Docker 部署 Spring Boot 项目项目开发完剩下的就是部署上线。我推荐的部署姿势是 Docker Compose把 MySQL、Redis、MinIO、后端应用、Nginx 五件套编排到同一个网络里。后端应用的Dockerfile很标准FROM openjdk:8-jdk-alpine VOLUME /tmp COPY target/photo-forum-0.0.1-SNAPSHOT.jar /app/app.jar ENTRYPOINT [java, -Djava.security.egdfile:/dev/./urandom, -jar, /app/app.jar]然后 docker-compose.yml 里把端口映射、数据卷、环境变量都写好一条docker compose up -d全部启动。这个地方有个教训镜像里的时区默认是 UTCJava 的LocalDateTime.now()拿到的会差 8 小时。我一开始没注意导致所有作品发布时间都晚了 8 个小时。必须在 Dockerfile 里加上ENV TZAsia/Shanghai并同步设置容器的时区。5.2 小程序备案与年审上架前的几道关卡微信小程序的审核和上架比想象中要繁琐尤其是涉及社交和 UGC 内容类目选择很关键。摄影交流平台涉及的类目通常是“社交-社区”或者“工具-信息查询”。我申请时用了“社交-社区”这个类目需要提供《增值电信业务经营许可证》或相关资质证明。个人开发者没有资质只能走“个人主体”限定类目很多功能会被限制。如果是以公司名义申请材料齐全就顺利得多。备案和年审不要拖到最后一刻。小程序名称、头像、简介都要提前准备好而且它们和 App 的审核规则不完全一样不能包含“最”“第一”“国家级”等绝对化用语。年审到期前 30 天小程序管理后台会提示不及时发现的话主体的小程序会被暂停服务。5.3 真机调试的典型问题到这步你会发现后端写得好好的一到真机各种诡异问题就冒出来了。我整理了三个最典型的。第一个是开发者工具里一切正常真机白屏。多半是 HTTPS 证书问题。小程序正式环境要求所有请求域名必须是 HTTPS且要在小程序后台配置 request 合法域名。我初期用 IP HTTP 调试只能打开“不校验合法域名”开关跑通流程上线前差点忘了切回来。第二个是图片加载不出来。MinIO 返回的 URL 用 IP 访问没问题但小程序里的图片域名同样需要在 downloadFile 合法域名里配置。如果图片域名和接口域名不是同一个还得单独配。第三个是 401 频繁触发。这是时间同步问题。手机本地时间不准JWT 的exp签发基于服务器时间如果本地时间晚于服务器token 校验永远通过不了反之亦然。我最后把 token 有效期设得足够长并在小程序启动时同步一下服务器时间才彻底解决。5.4 排查利器日志与 jar 包反编译上线之后出问题第一件事永远是查日志。Spring Boot 默认日志输出到控制台部署成 Docker 容器后docker logs -f就能实时查看。我建议把日志输出到文件并做按天分割用logback-spring.xml配置日志文件挂载到宿主机目录出了问题直接tail -f指定文件。还有一个冷门技能当线上运行的 jar 包和本地代码不一致的时候学会反编译 jar 包可以应急定位问题。你可以用 IDEA 直接打开 jar 包下的.class文件IDEA 自带反编译器能直接看到源码。网上也有一些工具可以反编译整个 jar比如CFR、JD-GUI。这个方法在排查“为什么我改的代码没生效”这种问题时特别有效往往发现是打包忘记刷新或者分支拉错了。我个人在实际开发中的几点体会这个项目从头到尾做下来最难的不是某个技术点而是把“摄影交流”这个抽象概念转化成一个个具体的数据结构。你在设计表结构和接口的时候一定要先想清楚用户是怎么使用的。比如首页信息流用户是打开就知道怎么刷那么就要保证 1 秒内能出首屏比如发布页要让用户 30 秒内完成选图、写标题、打标签、发布整个流程。另外给你一个建议开发顺序上先做后端再做小程序。后端做一半的时候就用 Postman 或 Apifox 把关键接口测通至少把登录、上传、列表三个核心接口先跑顺。小程序端很多页面都要依赖接口数据来调样式接口不稳前端装饰得再好看也是空中楼阁。最后再说一个小技巧开发期间把小程序端的调试基础库版本固定住别“使用最新版本”否则微信平台每次发版都可能带来不兼容变化。我的做法是开发时固定在 2.30.x上报问题时再切到最新版复现。这个小习惯帮我避开了好几次莫名其妙的样式错乱。摄影交流平台这种项目麻雀虽小五脏俱全做完之后你对 Spring Boot 和小程序开发的理解会深一个层次。照着这套思路做项目推进会很顺也祝你少踩几个我踩过的坑。