一个新产品要求快速上线后台管理功能时，我选择在 Guns 的基础上改造，而不是从零制作所有页面。项目其他服务已经采用 Spring Data JPA，因此将后台的数据访问层也调整为 JPA，希望减少两套数据访问逻辑并行维护的成本。
为什么没有直接使用原项目
当时 Guns 使用 MyBatis，而我们的公共数据层采用 JPA。两者并非不能共存，业务层也可以通过接口隔离，但在这个项目中继续维护两套映射与查询会增加同步成本。这是团队上下文中的选择，不表示 JPA 普遍优于 MyBatis。
改造后的项目是 guns-lite，在当时版本中使用 Spring Boot、Spring Data JPA、Shiro、Druid、Ehcache，以及 Beetl 和 Bootstrap。这里描述该次实现，不代表当前上游项目的完整技术栈。
功能开发与改造同时进行的代价
项目没有在最初预计的两周内上线。业务和外部需求变化期间，老版本继续开发，新版本持续追赶，最终约两周后才完成替换。这段时间维护两套实现，消耗的不只是编码时间，还有需求同步和行为核对。
如果重做这种改造，我会先列出登录、权限、菜单、分页和关键业务的验收样例，再分块替换；为新旧实现设置明确停止条件，避免它们无限期追赶。
复用数据层不能只换注解
分页页码、事务、懒加载、查询排序和批量操作行为都要对照。共享 Service 应表达稳定的业务规则，而不是为了复用就把所有数据库操作暴露给后台。
权限校验和数据范围也需要重新验证：复用了 DAO，不等于自动复用了调用者应有的授权。代码生成可以减少表单和简单 CRUD，但不能生成完整的状态约束与业务异常处理。
开源改造的边界
选择脚手架时，先确认许可证、维护状态、依赖和可替换部分，再估算定制与持续升级成本。适合本团队的二次开发，可以提供参考，但使用者仍需根据自己的版本和业务验证，而不是把项目截图当成已经适配的证明。
项目地址：enilu/guns-lite。