企业官网建设流程全解析

先说说为什么会写这个话题。前阵子有人拿「python+spingboot图书互换系统 图书借阅管理系统」这个题目来找我，说他打算在 Spring Boot 项目里塞一个 Python 模块，问我怎么拆才不别扭。题目里的 spingboot 拼写虽然有点随意，但一看就知道说的是 Spring Boot。这种组合在毕业设计、综合实训和个人练手项目里很常见，可网上的资料要么是纯 Java 的借阅管理，要么是纯 Python 的数据采集，很少有把两边串成一套完整系统的。

我这次要聊的，就是一套同时支持图书互换和图书借阅的管理系统。简单说，用户可以登记自己的闲置图书，既能借给别人，也能发起换书；系统负责记录借还周期、处理逾期提醒、撮合互换请求，同时用 Python 补齐图书信息、算点热门排行和简单推荐。听起来功能不复杂，但真做起来会踩不少坑。这篇文章适合谁看？正在做同类课题的学生、想练手前后端加服务拆分的开发者，以及想给小型书友会做个内部工具的人。全程没有炫技，都是能干完活的路子。

1. 需求拆解：图书互换和借阅管理其实是两套业务逻辑

1.1 互换与借阅的本质区别

很多人一上来就建一张「图书表」，再建一张「借阅记录」，结果做着做着发现不对劲——互换和借阅根本不是一回事，硬塞在一起会让状态管理变成一团乱麻。

借阅是中心化的：一本书归属于某个主人，主人把它借给另一个人，借的是一段时间内的使用权，到期必须归还，所有权从来不变。而图书互换是去中心化的：两本书分别在两个人手里，A 看上了 B 的书，愿意拿自己的一本书交换，成交之后双方都拿到了之前不属于自己的书，所有权发生了转移。借阅关心的是「什么时候还、有没有逾期」，互换关心的是「谁发起、谁接单、什么时候互相转移」。

这两条业务线如果共用一套状态字段，一定会打架。比如一本书处于「借出中」状态，同时又收到互换请求，怎么处理？如果状态里只有「可借/不可借」，那就会把互换的中间过程丢失掉。所以我做这个系统时，第一原则就是：从数据模型上就把两条业务线拆开，互相独立，只在「书的实物状态」上做统一约束，避免同一本书同时被借出和换走。

1.2 功能清单要控制在自己能交付的范围内

接手这类项目最常见的问题不是功能太少，而是功能太多。我见过有人给图书互换系统设计了一整套积分商城、在线聊天、物流跟踪，最后连登录都还没跑通。做项目要抓住主干，先交付一个能演示、能自洽的闭环。

我梳理这套系统时，功能清单控制在下面这个范围：

这套清单的主线非常清楚：用户管理自己的书，能借也能换，管理员能兜底，Python 三件事全是辅助能力。按这个范围做，一个 6-8 周的综合实训周期是能完成的。

2. 技术选型：双技术栈不是炫技，是各干各擅长的活

2.1 Spring Boot 为什么当主后端

主业务系统放着 Python 不用，主要原因不是性能，而是工程化顺手。图书互换和借阅管理本质是一堆 CRUD、几套状态流转和一组权限控制。Spring Boot 在这类场景里积累了几年的轮子：MyBatis-Plus 或者 Spring Data JPA 可以直接建表映射，Spring Security 加 JWT 做登录鉴权很成熟，声明式事务一个注解就能搞定跨表更新。

尤其处理互换成交这种「两本书同时变更归属」的操作时，事务一致性非常关键。Spring 的@Transactional配合 MySQL 行锁，能把并发问题控制得很好。Python 在这方面的生态不是不行，但同等复杂度下要自己搭的东西更多，调试成本更高。

另外从求职和毕设角度说，Spring Boot 在国内的接受度更高，很多单位看简历时对 Java 后端会有天然好感。选它当主后端，后续扩展成微服务也顺理成章。

2.2 Python 为什么不是多余的存在

有些人看到「python+springboot」会觉得是硬凑的技术栈。我自己做完才明白，Python 在这个系统里承担的是「Java 做起来很烦、Python 做起来很爽」的三件事。

第一是图书信息采集与补全。用户上架一本书时通常只愿意输 ISBN，剩下的封面、作者、出版社、简介不可能让人手敲。Python 的 requests、BeautifulSoup 生态和各类公开书库 API 对接起来非常快，Java 写类似的爬虫和解析会啰嗦不少。

第二是数据分析。借阅记录攒下来之后，管理员想知道哪些书最受欢迎、哪个分类借阅量最高、哪些用户是活跃书友，这类统计用 pandas 处理几行代码就能出结果。

第三是推荐算法。基于用户历史行为做物品推荐，Python 的生态最舒服，哪怕是手写一个余弦相似度协同过滤，代码量也远小于 Java 实现。

这三件事有一个共同点：它们都不是主业务的实时强依赖。Python 服务挂了，用户仍然能登录、上架、借阅、互换，只是新增图书时没法自动补全信息，首页推荐位空着而已。这种「辅助能力外置」的架构，正好解释了为什么不用 Python 重写整个系统——没必要，也不值当。

2.3 双栈通信方案：FastAPI 接口比硬编码调用干净

两个服务之间怎么通信？我的选择是 Spring Boot 用 HTTP 客户端调用 Python 服务暴露的 REST API，Python 端用 FastAPI 提供接口。为什么不直接用 Python 代码的函数？因为两个服务要独立部署、独立重启，硬嵌在一起失去了拆分意义。

FastAPI 是我比较推荐的，理由很实在：Pydantic 自带请求参数校验，Spring Boot 传过来格式不对会直接返回 422 错误，不用自己写过多的防御代码；自带 OpenAPI 文档，联调时在浏览器里就能调试接口；async 支持在处理采集任务的等待时间上表现也更好。通信协议上统一用 JSON，两边都对 JSON 支持最好，不要自作主张用 XML。

比如说，Spring Boot 处理图书新增时，发现库里没有这本书的详情，就拼一个请求打到 Python：

POST http://python-service:8000/internal/book/fill Content-Type: application/json { "isbn": "9787123456789" }

Python 服务返回统一结构，Spring Boot 再按这个结构落库。这里有一个关键点：外部请求路径上带internal，同时也要求服务间调用必须带上约定好的内部令牌，防止有人绕过主后端直接打 Python 服务的内部接口。后面联调章节我会详细说这个细节。

3. 数据模型与接口契约：双端都认的是同一套语言

3.1 核心表设计：书目和实物必须分开

这一节是整篇文章我觉得最值得停下来看的部分。图书互换系统出问题，十有八九出在数据表没分清「书目信息」和「实物图书」。

所谓书目信息，是这本书的公共属性：书名、作者、ISBN、出版社、封面图、简介。一本《某某数据结构》可以有很多本实体，但它们共享同一个书目信息。所谓实物图书，是某个人手上具体的那一本，它有归属人、有当前状态、有上架时间。

所以表结构至少要有这两层：

这张表里最关键的是book_item.status字段。它决定了一本书当前能不能被借、能不能被换。我设计了几个状态：

• AVAILABLE：可借可换，正常在架。
• BORROWED：已借出，等待归还。
• LOCKED：被某个互换请求暂时锁定，不能再被别人发起借阅或互换。
• OFF_SHELF：下架，可能被管理员处理或用户暂停共享。

这个状态非常像电商里的库存状态。同一本书如果同时被借阅和互换请求命中，会产生「超卖」问题，所以后面处理并发时要用锁来保证同一时刻只能有一个流程修改它的状态。

借阅记录表里还要冗余一个owner_id，虽然看起来可以通过 item 反查，但保留它是为了让历史记录不受后续图书归属变更影响。比如某本书已经通过互换换了新主人，旧借阅记录还要能显示当时是谁借给谁的。

3.2 统一响应体与服务间状态码约定

两个语言的服务对接，最怕各写各的返回结构。Spring Boot 接口可能返回{success: true}，Python 返回{code: 200}，前端就疯了。所以我提前定了一份两服务必须遵守的响应体：

{ "code": 0, "message": "ok", "data": {} }

code=0代表业务成功。非零为业务错误码，我按模块划分了几类：

业务错误和 HTTP 状态码没有必要一一对应。前端或者 Spring Boot 客户端统一判断code字段即可，HTTP 200只能说明请求被服务器处理了，业务到底成没成功，还是得看code。

Python 服务返回给 Spring Boot 的接口也遵守同一套规则。比如推荐接口返回{code: 0, message: "ok", data: {book_ids: [1,2,3]}}，Spring Boot 拿到book_ids后再查出完整书目返回给前端。这样双端对契约的理解完全一致，联调时少吵很多架。

3.3 字段命名：驼峰还是下划线，定死一件事

Java 习惯用驼峰，Python 习惯用下划线，JSON 字段本身就是前方一致的关键。我的建议是：所有跨服务 JSON 字段一律使用下划线命名。

Spring Boot 端通过 Jackson 配置把 Java 驼峰字段序列化成下划线，或者干脆在 DTO 上用@JsonProperty("due_time")显式声明。Python 端 Pydantic 的字段名直接按下划线设计，两边天然对齐，避免前面加了一层字段转换代码，后面维护起来要么只改一半要么改错位置。实际项目里我见过太多时间字段一会儿是dueTime一会儿是due_time造成的低级联调事故。

4. 核心业务实现：借阅闭环与互换状态机

4.1 借阅流程：一个并发问题差点让我翻车

借阅流程看起来简单：用户点借书，系统把书标记为已借出，生成借阅记录，到期自动提醒。但真写代码时，「同一本书被两个人同时借走」的问题就来了。

在单体小系统里，最简单的解法是 MySQL 的行锁。查询图书时加上FOR UPDATE，把这一行锁住，等整个借阅逻辑提交后再释放。Spring Boot 里的核心方法像这样：

@Transactional public BorrowResult borrow(BorrowRequest req) { // 锁定 book_item 这一行，防止并发借阅 BookItem item = bookItemMapper.selectByIdForUpdate(req.getItemId()); if (item == null) { throw new BusinessException(2001, "图书不存在"); } if (item.getStatus() != BookStatus.AVAILABLE) { throw new BusinessException(2002, "图书当前不可借阅"); } if (item.getOwnerId().equals(req.getBorrowerId())) { throw new BusinessException(1003, "不能借自己的书"); } // 更新实物状态 item.setStatus(BookStatus.BORROWED); bookItemMapper.updateById(item); // 生成借阅记录 LocalDateTime now = LocalDateTime.now(); BorrowRecord record = BorrowRecord.builder() .itemId(item.getId()) .borrowerId(req.getBorrowerId()) .ownerId(item.getOwnerId()) .borrowTime(now) .dueTime(now.plusDays(req.getDays())) .status(BorrowStatus.BORROWING) .build(); borrowRecordMapper.insert(record); return BorrowResult.ok(record.getId()); }

这里最核心的是selectByIdForUpdate。它就是SELECT ... FOR UPDATE，事务提交前别的线程对这个book_item的更新会被阻塞。这个方案足够应付几百人小社区的场景。如果以后要做成高并发的全网换书平台，再考虑 Redis 分布式锁也不迟——普通毕设和内部工具直接上分布式锁其实是给自己增加无谓的复杂度。

还书流程同理，注意校验「只能由借阅者本人或图书主人归还」，归还后把book_item.status改回AVAILABLE，同时更新borrow_record.status为RETURNED，写入return_time和实还时间。逾期判断不要靠任务扫描硬算，可以在查询记录列表时动态计算：当前时间 > due_time 且 return_time 为空即为逾期，逾期天数用于前端展示和管理员筛选。

4.2 互换状态机：为什么不能用一堆 if-else

互换是最容易写乱的部分，因为一个订单的生命周期有多个阶段，每个阶段能做的操作不一样。用 if-else 判断状态虽然也能跑，但随着状态增多会越来越难维护，最后可能会出现「已取消的订单还能被确认成交」这种事。

我用的方案是显式状态机。互换订单的状态定义为一个 Java 枚举：

public enum SwapOrderStatus { PENDING, // 发起方已提出互换，等待接收方处理 ACCEPTED, // 接收方同意互换，双方进入成交阶段 REJECTED, // 接收方拒绝互换 EXCHANGED, // 双方确认完成，图书归属已变更 CANCELED; // 任意一方取消订单 private static final Map<SwapOrderStatus, Set<SwapOrderStatus>> ALLOWED_TRANSITIONS; static { Map<SwapOrderStatus, Set<SwapOrderStatus>> map = new HashMap<>(); map.put(PENDING, Set.of(ACCEPTED, REJECTED, CANCELED)); map.put(ACCEPTED, Set.of(EXCHANGED, CANCELED)); map.put(EXCHANGED, Set.of()); map.put(REJECTED, Set.of()); map.put(CANCELED, Set.of()); ALLOWED_TRANSITIONS = map; } public boolean canTransitTo(SwapOrderStatus target) { return ALLOWED_TRANSITIONS.getOrDefault(this, Set.of()).contains(target); } }

每次状态变更时都先检查canTransitTo，不允许直接跳变。这样即使以后加一个「运输中」状态，也只是在PENDING和EXCHANGED之间插入一环，不会影响已有逻辑。状态机读起来也直观，接手维护的人一眼就能看出整个互换业务的完整流转路径。

互换成交是整个系统里唯一同时动两本书所有权的操作。确认EXCHANGED时，需要在一个事务里完成：

1. 校验双方图书仍处于LOCKED或AVAILABLE状态。
2. 把发起方的book_item.owner_id改为接收方。
3. 把接收方的book_item.owner_id改为发起方。
4. 把两边book_item.status都改为AVAILABLE。
5. 更新swap_order.status = EXCHANGED，记录finish_time。

这套操作必须整体回滚，用@Transactional可以保证：如果中间任何一步失败，两本书的归属不会出现一半成功一半失败的情况。

4.3 权限控制：越权漏洞是这类系统的通病

图书互换系统的越权玩法特别多：B 用户能不能把 A 用户发起的互换订单改成已成交？普通用户能不能调用管理员接口封禁别人？上架的书能不能直接改别人名下的记录？

这类问题在安全领域叫 IDOR（不安全的直接对象引用），常见原因就是接口只校验了「是否登录」，没校验「是否是资源的主人」。Spring Security 中把 URL 级别的权限控制做好只算第一步，数据级别的权限必须在业务代码里显式判断。

比如接收方处理互换请求时，写代码要这样：

SwapOrder order = swapOrderMapper.selectById(req.getOrderId()); if (!order.getReceiverId().equals(currentUserId)) { throw new BusinessException(1002, "无权限操作该互换订单"); }

再比如用户查询自己的借阅记录，SQL 里必须带上WHERE borrower_id = ?，而不是查出全部记录再按前端显示。这类代码写起来不复杂，难的是每次都记得写。我的习惯是写每个接口前先问自己一句：当前用户对操作目标有没有合法身份？没有就挡回去。

服务间的internal接口也需要鉴权。Spring Boot 调 Python 时在 Header 中带一个约定好的 token，Python 端用 FastAPI 的依赖项检查，token 不对直接返回 401。这一步很多人会忽略，以为内部接口部署在内网就安全，实际上内网也不是保险箱。

5. Python 侧的能力实现：信息补全、热门榜与轻量推荐

5.1 ISBN 图书信息自动补全

用户在 Spring Boot 端填 ISBN 时，主后端先查本地book表，没有就调用 Python 服务。Python 服务的核心逻辑有两层：先查本地缓存，再查第三方公开书库接口。限于合规要求，我强调一下：对接的一定是公开可用、允许调用的书库 API 或开放数据服务，绝不涉及绕过登录、破解接口、抓取禁止访问的数据这些行为。

Python 端代码大概长这样：

from fastapi import APIRouter, Depends, Header from pydantic import BaseModel import requests router = APIRouter(prefix="/internal/book", tags=["book-fill"]) class FillRequest(BaseModel): isbn: str class FillResponse(BaseModel): code: int message: str data: dict | None @router.post("/fill") def fill_book(req: FillRequest, x_internal_token: str = Header(...)): if x_internal_token != INTERNAL_TOKEN: return FillResponse(code=1002, message="无权限", data=None) cached = get_book_from_cache(req.isbn) if cached: return FillResponse(code=0, message="ok", data=cached) data = query_public_book_api(req.isbn) if not data: return FillResponse(code=2001, message="图书不存在", data=None) set_book_cache(req.isbn, data) return FillResponse(code=0, message="ok", data=data)

这里最需要注意的是幂等和频率控制。外部书库接口不是自家数据库，不能每次都打。我的策略是：先查 Redis 缓存，再打接口，最后把结果写入本地数据库。同一本 ISBN 无论被人搜索多少次，外部接口最多被调用一次。另外要在外部接口调用前做isbn格式校验，比如常见的 10 位/13 位校验码规则，格式不对就直接返回参数错误，不能把脏数据发到外部服务。

再加一层兜底逻辑：外部接口超时或返回异常时，Python 服务返回一个降级结果，Spring Boot 前端这时可以让用户手动填写书名和作者，而不是整个上架流程崩掉。辅助服务必须有「允许失败」的觉悟，这是我把 Python 能力设计成独立服务的核心原因。

5.2 借阅热度分析与热门榜单

热门榜几乎是每个这类系统的标配。Python 侧从borrow_record表取数，统计一段时间内借阅次数最高的图书，按分类聚合成榜单。

import pandas as pd from sqlalchemy import create_engine engine = create_engine(MYSQL_CONN) def hot_books(days: int = 30, limit: int = 10): sql = """ SELECT item.book_id, COUNT(*) AS borrow_count FROM borrow_record br JOIN book_item item ON br.item_id = item.id WHERE br.borrow_time >= NOW() - INTERVAL %(days)s DAY GROUP BY item.book_id ORDER BY borrow_count DESC LIMIT %(limit)s """ df = pd.read_sql(sql, engine, params={"days": days, "limit": limit}) return df.to_dict(orient="records")

统计结果直接按book_id返回，Spring Boot 再去查book表补全书名封面。这个分工很清晰：谁的数据谁算，算完交给展示层。

分析任务的执行我推荐用简单方案：不放 Celery。这套系统数据量不大，远程定时任务误用了分布式任务队列反而是负担。可以用 FastAPI 启动时的定时任务调度，或者 Python 服务内置 APScheduler 每 30 分钟刷新一次榜单缓存。查询时先读缓存，缓存没有再去数据库算。一个热榜接口对实时性的要求本来也不高，给用户看到的是五分钟前的数据完全没问题。

5.3 一个够用的推荐接口：手写协同过滤就够了

推荐功能是这类系统的加分项。很多人一听推荐就想到深度学习，完全没必要。数据量刚过百条时，一个简单的「基于用户的协同过滤」就能给用户带来「诶它怎么知道我想看这个」的惊喜感。

思路是这样的：

1. 构建用户-图书借阅矩阵：行是用户，列是图书，值是该用户借阅过这本书的次数或评分标识（比如借过为 1，未借过为 0）。
2. 计算当前用户和其他用户的余弦相似度： 两个向量的相似度 = 两个向量的点积 / 各自模长的乘积。 在矩阵中，「用户 A 借过书 1 和书 2，用户 B 借过书 2 和书 3」时，A 和 B 的相似度主要取决于共同借过的书。
3. 找出最相似的 K 个用户，把 TA 们借过但当前用户没借过的书推荐出来。

核心代码也不复杂：

import numpy as np def recommend_for_user(user_id: int, user_item_matrix, item_ids, k=5, limit=10): idx = user_index[user_id] sims = cosine_similarity(user_item_matrix[idx:idx+1], user_item_matrix)[0] candidates = {} top_user_indices = np.argsort(-sims)[:k+1] for other_idx in top_user_indices: if other_idx == idx: continue for j in range(user_item_matrix.shape[1]): if user_item_matrix[other_idx, j] > 0 and user_item_matrix[idx, j] == 0: candidates[j] = candidates.get(j, 0) + sims[other_idx] sorted_items = sorted(candidates.items(), key=lambda x: -x[1])[:limit] return [item_ids[j] for j, _ in sorted_items]

相似度的计算用 numpy 做向量运算，百级用户规模下毫秒级完成。做好缓存，不用每次请求都重新构建矩阵。

5.4 Python 服务挂了的兜底策略

前面我说 Python 服务是辅助能力，所以 Spring Boot 调用它时必须做好容错。我在 Java 端用了try-catch+ 超时控制 + 默认值兜底：

1. 设置 HTTP 调用超时为 2 秒，Python 服务没响应就直接走降级逻辑，不让前端用户一直转圈。
2. 捕获异常后返回默认值：图书信息补全失败就提示用户手动输入，推荐接口失败就返回热门榜前几名。
3. 使用简单的熔断状态：如果 Python 连续不可用，Spring Boot 侧可以在本地内存标记服务失效，接下来 30 秒内不再发起对 Python 的请求，直接走降级，避免请求堆积拖垮主系统。

很多人做双栈项目时只关注「怎么调通」，忽略了「调不通怎么办」。在生产环境，服务失败是常态，设计时就要默认它一定会出问题。这一点做透了，系统质量会上一个台阶。

6. 联调与部署实战：跨语言项目最容易翻车的地方

6.1 三个跨语言坑：时间格式、Long 精度、编码

双栈联调时，我踩过或者帮别人排查过的问题，基本都集中在这三处。

第一，时间格式。Spring Boot 默认序列化LocalDateTime的格式可能带不带T取决于 Jackson 配置，FastAPI 默认接受 ISO 8601 格式。如果两边没对齐，会出现2025-06-01 12:00:00和2025-06-01T12:00:00互相解析失败的问题。我的做法是统一用yyyy-MM-dd HH:mm:ss字符串传输，在 Spring Boot 里通过@JsonFormat标注，Python 端用 Pydantic 解析字符串后手动转datetime。跨语言项目别依赖框架的默认行为，显式定义最稳。

第二，Long 精度。MySQL 主键如果用雪花算法或自增 Long，Java Long 本身没问题，但一旦经过 JSON 传输到前端 JavaScript，超出Number.MAX_SAFE_INTEGER（约 9007199254740991）后就会丢精度。Python 虽然支持大整数，但如果前端把 id 当成数字处理，同样会踩坑。解决办法是在 Spring Boot 端把主键字段序列化为字符串，DTO 里定义成String，Python 端也按str类型接收。图书互换里可能涉及用户 id、图书 id，这个坑务必提前预防。

第三，编码。Windows 上开发时，Python 爬虫请求第三方接口返回的中文容易出现乱码，根源是响应头里的charset与实际内容编码不一致。处理办法是只用resp.encoding = "utf-8"显式指定，Spring Boot 侧接收 Python 返回的 JSON 时也统一用 UTF-8。别相信默认值，别在代码里写平台相关的编码判断。

6.2 数据库索引与搜索优化

这套系统到上线阶段，用到的数据表不算多，但几个高频查询字段一定要建索引。我按实际查询场景加了这些索引：

• book_item(owner_id)：用户查看我的书架时按主人查。
• book_item(status)：系统查找可借/可换图书时按状态过滤。
• borrow_record(borrower_id, status)：用户查我的借阅列表。
• swap_order(initiator_id)和swap_order(receiver_id)：用户查我发起的/收到的互换请求。
• book(isbn)唯一索引：防止同一本 ISBN 生成多条公共书目。

搜索功能我建议分阶段实现。起步阶段数据量几千条，直接LIKE '%关键词%'完全够用，不用纠结。等数据上到几万条、搜索开始变慢，再考虑 MySQL 全文索引或者独立的全文检索服务。过早引入搜索引擎，项目复杂度指数上升，收益却几乎为零。做项目控制复杂度本身就是一种能力。

6.3 Docker Compose 一键部署方案

双栈项目最大的部署问题是环境不统一。开发时两台机器 JDK 版本不一样、Python 依赖不一致，就会上演「在我机器上能跑」的戏码。所以我直接用 Docker Compose 把这套系统编排起来了，本地一套环境，部署到服务器也一套环境。

大致编排为四个容器：

docker-compose.yml的核心配置长这样：

services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: rootpass MYSQL_DATABASE: book_swap volumes: - ./init.sql:/docker-entrypoint-initdb.d/init.sql - mysql-data:/var/lib/mysql app-java: build: ./backend depends_on: - mysql - redis - python-service environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/book_swap PYTHON_SERVICE_URL: http://python-service:8000 python-service: build: ./python_service depends_on: - mysql - redis volumes: mysql-data:

注意 Spring Boot 容器里不能写localhost连数据库，要写服务的容器名mysql。PYTHON_SERVICE_URL里也不能写127.0.0.1，要写http://python-service:8000。这类「本地能跑，Docker 里不行」的问题，十有八九是服务名写错了。

对外统一入口用一个 Nginx 把前端静态文件和 Spring Boot API 绑在一起，Python 服务不对外暴露，只能由 Spring Boot 通过容器网络访问。这样一来，外部攻击面就小了很多。

6.4 实测数据准备与演示经验

开发过程中一定要准备一批像样的测试数据。我吃过亏：系统功能做完了，演示时发现书架上空荡荡，推荐接口算出来全是空列表。图书互换系统的演示效果强依赖数据密度，数据少，互换和推荐功能根本展不开。

我建议至少准备 20 个模拟用户、50 本公共书目、100 本实物图书，再手工造一批借阅和互换记录，时间尽量分布在一个月内，这样热门榜和推荐推荐结果都有内容可看。用户数据完全用假数据生成程序批量造，不能自己一个一个手工录入。

还有一个演示技巧：给每本书的封面图准备真实的图片 URL 或者本地上传路径，首页一打开视觉冲击力比纯文字列表强很多。这不算花里胡哨，是图书类产品的基本观感要求。

最后说几句个人体会

这套系统做完之后，我最大的感受是：双技术栈项目最怕的不是技术难，而是职责混在一起。Spring Boot 干主业务，Python 干辅助能力，两边只靠接口和共同的数据表打交道，边界非常清楚。项目后期几乎不需要改对方代码，各改各的，只要接口契约不变就非常省心。

如果现在让我重做一遍，我可能会在做数据表设计时再先多想半天，尤其是book和book_item的分层，这套设计直接决定了后续借阅和互换能不能并行跑。新手上路我也建议按照这种次序来：先把 Spring Boot 主业务闭环跑通，再加 Python 的信息补全，最后再做分析和推荐。别一开始就把两边代码同时铺开，否则联调的时候你会发现自己根本不知道到底是谁的 bug。

最后分享一个小技巧：跨语言联调之前，先把两边的接口文档导出来对着过一遍，尤其是字段名和类型。这一步做足十分钟，能省掉后面可能两三天的问题定位时间。开发这类系统，提前省下的时间，永远比过程中多写的代码更值钱。