SpringBoot+Vue共享单车管理系统实战：数据模型与前后端实现-平芜编程栈

我在之前协助过不止一个共享单车/电单车运营团队搭建内部管理系统，其中"springbo"这个项目代号印象比较深：团队要求用一套能从零管理车辆、订单、运维工单的数据后台，前后端选型定了SpringBoot+Vue，持久层用MyBatis，数据库落在MySQL。这套组合在中小规模业务里非常典型，既不像微服务那样重，又能把业务逻辑和数据存储理得明明白白。如果你正打算复刻或改造同类系统，这篇文章会把我在设计和实现过程中踩过、填过的坑，以及每一步为什么这么做，完整拆给你。

这篇文章适合三类人：一是刚接触全栈开发、想通过一个完整项目弄清SpringBoot和Vue怎么配合的初学者；二是共享出行领域的业务或研发人员，想知道车辆管理、订单流转和统计报表在工程上如何落地；三是准备做毕业设计或个人项目、需要一套稳的实现思路的开发者。下面所有内容都以"springbo共享单车数据存储管理系统"为背景展开，不涉及任何具体机构，纯项目经验分享。

1. 为什么一个小单车团队需要自己写管理系统

1.1 业务痛点和系统边界

共享单车的运营逻辑其实比很多人想象中更依赖数据：每天车辆被骑到哪里、哪些车长时间闲置、哪些车故障率偏高、运维人员处理报修是否及时，这些信息如果不能汇总到一个统一系统里，就只能靠Excel表格和微信群聊拼凑。早期我给某小型团队做过一次摸底，他们手上有一个电子围栏接口、一批蓝牙锁设备、还有人工巡检记录，数据源彼此隔离，运营调度全靠经验。这样的状态在车辆只有几百台时勉强能撑，一旦过千台，问题立刻暴露：车辆去向无据可查，丢失了都无法判定责任。

所以系统的边界不是"管理单车本身"，而是把车辆的生命周期数据化。一辆车从出厂投放、日常骑行、故障上报、维修入库到重新投放，每一步都要在系统里留下记录。订单数据还要支撑后续的区域热力分析、潮汐调度。当时我和团队定的范围就很清晰：不做实时定位推送，不做支付清结算，核心先覆盖车辆档案、骑行订单、故障运维和基础统计报表。这能避免项目一开始就陷入过度设计。

1.2 前后端分离的选型理由

有人可能会问，为什么不用传统的JSP+Servlet、或者直接上若依这类脚手架？我的判断标准很简单：团队的技术惯性和后续维护成本。SpringBoot降低了很多底层配置负担，内嵌Tomcat让部署变成一条java -jar命令；Vue则能把复杂表格、筛选条件和图表交互拆成前端组件，和后端只通过JSON接口通信。这个组合尤其在页面交互要求高、报表需要动态刷新的场景里，开发效率明显更高。

比起把逻辑揉进JSP页面，前后端分离让两拨人可以并行开发。前后端职责边界清晰：后端只做鉴权、业务规则、数据持久化；前端只负责渲染和交互。就算团队里只有一个人既写后端又写前端，分离之后本地调试也更轻松——后端用Postman测接口，前端用Mock数据调页面，互不阻塞。另外，共享单车系统未来大概率要接小程序或App，Vue页面可以作为后台管理端的载体，而SpringBoot的接口天然可以复用给其他客户端，这是一笔非常划算的技术投资。

2. 数据库设计：车辆表如何撑起整个业务闭环

2.1 核心表结构该怎么拆

我习惯先画核心实体关系，再落SQL。springbo系统的主要实体包括车辆、订单、运维工单、用户和管理员。业务上"车"是绝对核心，所以bike表必须包含足够描述一辆车状态的信息。

一个比较合理的bike表设计如下：

CREATE TABLE `bike` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `bike_no` varchar(32) NOT NULL COMMENT '车辆编号，业务唯一', `lock_type` tinyint(4) DEFAULT 0 COMMENT '锁类型：0-机械锁 1-蓝牙锁 2-NB锁', `status` tinyint(4) DEFAULT 1 COMMENT '车辆状态：1-空闲 2-骑行中 3-故障 4-维修中 5-报废', `longitude` decimal(10,7) DEFAULT NULL, `latitude` decimal(10,7) DEFAULT NULL, `battery` int(11) DEFAULT 100 COMMENT '电量百分比（电单车）', `total_ride_count` int(11) DEFAULT 0 COMMENT '累计骑行次数', `total_ride_duration` bigint(20) DEFAULT 0 COMMENT '累计骑行时长（秒）', `last_ride_time` datetime DEFAULT NULL COMMENT '最后骑行时间', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_bike_no` (`bike_no`), KEY `idx_status` (`status`), KEY `idx_longitude_latitude` (`longitude`, `latitude`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='共享单车车辆表';

车辆编号必须加唯一索引，这算是我踩过的第一个坑。曾经有同事在批量导入时没做唯一约束，结果同一辆车在系统里出现了两条档案，后面的订单记录对不上，排查了一整天才发现是源头数据重复。别把唯一性只寄托在业务代码判断上，数据库约束永远是最后一道防线。

状态字段我建议用tinyint而非字符串，存储空间更小，查询效率也更高。业务代码里再做一层枚举转换，前端拿到的是有意义的文字描述，后端存储的是紧凑数值，两头都不吃亏。

2.2 骑行订单与运维工单的数据组织方式

骑行订单表是系统里数据增长最快的表，设计时要想清楚查询维度。一张ride_order表至少应该包含这些字段：

CREATE TABLE `ride_order` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_no` varchar(64) NOT NULL COMMENT '订单号', `bike_id` bigint(20) NOT NULL, `user_id` bigint(20) DEFAULT NULL, `start_time` datetime NOT NULL, `end_time` datetime DEFAULT NULL, `start_lng` decimal(10,7) DEFAULT NULL, `start_lat` decimal(10,7) DEFAULT NULL, `end_lng` decimal(10,7) DEFAULT NULL, `end_lat` decimal(10,7) DEFAULT NULL, `duration` int(11) DEFAULT 0 COMMENT '骑行时长（秒）', `amount` decimal(10,2) DEFAULT 0 COMMENT '金额', `status` tinyint(4) DEFAULT 0 COMMENT '0-进行中 1-已完成 2-异常关闭', PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_bike_id_start_time` (`bike_id`, `start_time`), KEY `idx_user_id_start_time` (`user_id`, `start_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='骑行订单表';

复合索引在这里很关键。单独给bike_id建索引，在「查某辆车的最近订单」这个高频场景里性能没问题；但如果还要按时间过滤，仅靠单列索引会导致回表次数多。我当时在预发环境造了十万条订单数据做压测，发现(bike_id, start_time)的复合索引让查询耗时从几百毫秒降到几十毫秒，效果立竿见影。

运维工单表则要记录报障、派单、处理、验收这几个环节。常见设计是把处理状态位和维护人员ID直接放在工单表上：

CREATE TABLE `maintenance_order` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `work_no` varchar(64) NOT NULL COMMENT '工单号', `bike_id` bigint(20) NOT NULL, `report_user_id` bigint(20) DEFAULT NULL COMMENT '上报人', `fault_desc` varchar(255) DEFAULT NULL, `handler_id` bigint(20) DEFAULT NULL COMMENT '处理人', `handle_status` tinyint(4) DEFAULT 0 COMMENT '0-待派单 1-处理中 2-已完成 3-已关闭', `handle_result` varchar(255) DEFAULT NULL, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `finish_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_bike_id_status` (`bike_id`, `handle_status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='运维工单表';

业务上有一种经典做法：故障车辆报修后，bike表状态立刻改为"故障"，同时生成一条待派单工单。只有当工单流程走到"已完成"时，车辆状态才能回置为"空闲"。这个联动关系如果只靠代码里随手写update，很容易出现"车修好了但车辆状态还是故障"的脏数据。我的建议是，把状态变更收敛到同一个Service方法里，用事务保证两步操作要么全成功、要么全回滚。

2.3 经纬度字段与位置查询的注意事项

车辆表和订单表里都有经纬度字段，我用的是decimal(10,7)，原因是MySQL的float/double在比较相等和范围查询时存在精度问题，同时MySQL从8.0开始支持geometry类型，但业务里大部分场景只是"保存最新坐标并展示"，几何类型的序列化反而增加复杂度。点到为止，如果后续真要做"附近车辆"这类LBS查询，可以引入MySQL的空间索引，或者把坐标同步到ES里，这是另一个话题了。

还有一个细节容易被忽略：经纬度字段不要用varchar存，否则排序、距离计算都会变成字符串行为，这是我在一次区域统计口径核对时发现的。当时区域查询出来老是少车，最后定位发现是经纬度精度被截断导致边界点没有匹配上，从那以后凡涉及地理坐标我都用decimal并严格控制精度。

3. 后端实现：鉴权、车辆CRUD和订单状态机的落地代码

3.1 项目分层结构一图看懂

SpringBoot项目如果分层清晰，后续加功能会非常省心。我在springbo系统里使用的是一种非常常规但有效的包结构：

com.springbo.admin ├── controller # 接口层，只做参数接收和响应包装 ├── service # 业务层，核心逻辑 │ └── impl ├── mapper # MyBatis接口 ├── entity # 数据库实体 ├── dto # 前端交互对象 ├── vo # 视图对象 ├── config # 配置类 ├── interceptor # 拦截器（登录鉴权等） └── common # 公共类（统一响应、异常处理）

我特别推荐把请求进来的参数和返回出去的响应对象区分开。不要直接拿entity往前端甩，因为数据库实体里有些字段（比如create_time、update_time）前端并不关心，直接暴露容易泄漏内部实现细节。用DTO接收参数、VO输出结果，隔离变化，这在项目后期维护时收益极高。

3.2 统一登录鉴权：拦截器加JWT的简易方案

后台管理系统如果没有鉴权，等于把管理接口裸奔在公网上，这在共享单车场景里尤其危险——有人可以随意改车辆位置。springbo系统的方案是SpringBoot拦截器+JWT令牌。登录接口校验管理员账号密码成功后，签发一个有效期为24小时的token，前端每次请求在请求头带上Authorization，拦截器统一解析校验。

核心拦截器逻辑大约是：

public class AuthInterceptor extends HandlerInterceptorAdapter { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { token = token.substring(7); } try { Claims claims = Jwts.parser() .setSigningKey(secretKey) .parseClaimsJws(token) .getBody(); request.setAttribute("adminId", claims.get("adminId")); return true; } catch (Exception e) { response.setStatus(401); response.getWriter().write("{\"code\":401,\"msg\":\"token无效或已过期\"}"); return false; } } }

需要注意几个点：一是secretKey绝对不能写在代码里，要放到配置文件或环境变量，否则打包后源码泄露等于鉴权形同虚设；二是拦截器只做鉴权，真正的角色权限判断（比如只有超级管理员能删除车辆）建议再加一个注解加切面实现，不要全塞在拦截器里，否则代码会膨胀得很难看。

3.3 车辆管理模块的业务事务边界

车辆新增、编辑、删除这些基础CRUD看起来简单，但有一类问题值得专门说：事务边界。以"车辆删除"为例，一辆车如果有未完成的订单、未结清投运记录，直接物理删除会导致订单表里的bike_id变成无效引用。我更推荐逻辑删除——在bike表增加一个is_deleted字段，管理员删除车辆时，业务Service执行两步：先将车辆状态置为"报废"，再插入一条车辆生命周期变更记录。整个过程放在一个事务里，避免写了一半数据库崩溃导致状态不一致。

Service层的实现示例：

@Service public class BikeServiceImpl implements BikeService { @Autowired private BikeMapper bikeMapper; @Autowired private BikeLogMapper bikeLogMapper; @Transactional(rollbackFor = Exception.class) public void deleteBike(Long bikeId, Long operatorId) { Bike bike = bikeMapper.selectById(bikeId); if (bike == null) { throw new BizException("车辆不存在"); } Bike update = new Bike(); update.setId(bikeId); update.setStatus(BikeStatus.SCRAPPED.getCode()); bikeMapper.updateById(update); BikeLog log = new BikeLog(); log.setBikeId(bikeId); log.setOperatorId(operatorId); log.setAction("SCRAP"); log.setRemark("车辆报废处理"); bikeLogMapper.insert(log); } }

@Transactional(rollbackFor = Exception.class)这一行很关键。Spring事务默认只对RuntimeException回滚，如果业务代码抛了受检异常，不加rollbackFor就会导致事务不生效。网上有很多"注解加了但事务没生效"的案例，多半就是栽在这里。另外注意事务方法不能被同类内部调用，否则代理失效，这也是常见的坑。

3.4 订单状态机的正确打开方式

骑行订单状态之间是有严格顺序的：进行中只能变为已完成或异常关闭，异常关闭不能变回进行中。这种状态流转如果放任各处代码随便改status，系统很快就会出现"已完成的订单还能被再次结算"这类数据错乱。

我建议用一个枚举来定义状态流转合法性：

public enum OrderStatus { RIDING(0, "骑行中"), FINISHED(1, "已完成"), CLOSED(2, "异常关闭"); public static boolean canTransform(Integer from, Integer to) { if (from == null || to == null) return false; if (from == RIDING.getCode()) { return to == FINISHED.getCode() || to == CLOSED.getCode(); } return false; } }

然后在Service里统一走"结束订单"的入口方法，而不是让每个Controller都自己去写update status。这样规则只存在一处，测试也只需要针对这一口子设计用例。实际上后来上线运营时，第三方设备偶尔会推送重复的关锁信号，由于状态机限制了"已完成状态不能再次流转"，重复回调轻松被拦下，避免了订单被二次结算的问题。

4. Vue前端：管理后台的表格、筛选与可视化报表实现

4.1 前端项目结构与路由

Vue端我建议直接用Vue CLI或Vite初始化，配合Vue Router和Axios。springbo系统的前端结构大致是：

src ├── api # 接口封装 ├── assets ├── components # 通用组件 ├── views │ ├── Login.vue │ ├── Dashboard.vue # 仪表盘 │ ├── BikeList.vue # 车辆管理 │ ├── OrderList.vue # 订单管理 │ └── Maintenance.vue # 运维工单 ├── router └── store

一个容易被忽略的经验是：axios请求/响应拦截器一定要做统一异常处理。后端返回401时前端要自动跳转登录页；后端返回业务错误码时前端要弹出错误消息。如果没有这层处理，每个页面都要写一堆重复的try-catch和状态判断，代码冗余度会非常高，而且后端一旦调整错误码格式，前端会炸成一片。

4.2 数据表格和表单联动：车辆管理的常用模式

车辆管理页面的核心交互是：顶部搜索栏（按车辆编号、状态）、表格分页展示、行内操作按钮（编辑、故障上报、报废）。这块用Element UI或Ant Design Vue都能很快实现。搜索条件变化时重新拉取列表，这里的常见坑是分页参数重置——用户搜完结果后在第二页点重置搜索，应该跳回第一页，很多新手会漏掉，导致明明搜索条件变了，还在翻第N页。

一个实用规范：让查询参数、当前页码和每页条数都放进同一个响应式对象里，搜索方法里统一重置pageNum为1。如下：

const queryParams = reactive({ bikeNo: '', status: undefined, pageNum: 1, pageSize: 10 }); function handleSearch() { queryParams.pageNum = 1; loadBikeList(); }

表格列数据里，车辆状态我会直接渲染成Tag标签，不同状态用不同颜色，比如空闲是绿色、故障是红色、维修中是橙色。这种视觉化信息在运营人员每天盯屏的时候特别有用，比一列数字直观得多。

4.3 可视化报表：ECharts用来展示什么最合适

共享单车后台最核心的报表是"区域车辆分布"和"骑行时段热力趋势"。ECharts是标准选择，我用它做了两张图：一张是柱状图，展示各区域车辆数量；一张是折线图，展示24小时内的订单量变化。

有人问我为什么不在地图上撒点，原因是后端只聚合输出统计数据，前端拿到这些数据做图表展示成本最低。地图像散点图虽然酷，但需要前端承担坐标转瓦片、聚合圈选一大套复杂逻辑，在运营管理后台里属于锦上添花。头一版先把"今天骑了多少单、哪个区域车最少、什么时段高峰"这些问题回答清楚，才有继续做地图可视化的业务基础。

在ECharts配置里，需要注意坐标轴数据量过大的问题。如果后端返回的是按分钟颗粒度的数据，前端一次性渲染1440个点，交互会卡。可以用dataZoom组件让用户手动缩放，或者后端做归一化聚合，建议按小时聚合出24个点，信息损失不多但渲染压力小很多。

4.4 前后端联调：跨域和接口规范

本地开发时前端跑在5173端口，后端跑在8080端口，跨域问题必然出现。解决方式有两种：后端统一加CORS配置，或者前端通过Vite的proxy把/api代理到后端。我更推荐proxy方案，因为生产环境Nginx本来就会做一层反向代理，前端把请求路径写成相对路径，部署时更灵活。Vite里这样配置：

server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这里前后端接口规范有句经验：URL里别用大驼峰，统一小写加短横线，比如/api/bike/list，body里字段统一用驼峰形式（Java端jackson默认就是驼峰），前端别擅自改。我曾见过一个项目，后端返回值里既有userName又有user_name，前端代码里两种都在用，最后排查true/false判断问题找了好久。规范一旦定下来，要当成代码评审的硬指标。

5. 从源码到运行：MySQL配置、MyBatis映射和项目启动

5.1 环境版本选择与项目初始化

这套项目建议的 Java版本是JDK 1.8。虽然Spring Boot 2.x已经出了很久，但很多生产环境依然跑在8上，稳定且社区资料多。MySQL我建议5.7或8.0，8.0对UTF8MB4的支持更好一点，如果服务器上已经装了5.7，也完全够用。MyBatis用Spring Boot的starter可以直接集成。

后端项目的内部依赖大致是：spring-boot-starter-web、spring-boot-starter-jdbc、mybatis-spring-boot-starter、mysql-connector-java、jjwt、lombok和hutool。hutool这个工具库我格外推荐，它提供了ID生成、日期处理、Bean拷贝等非常实用的方法，减少大量样板代码。

5.2 MyBatis映射文件的几个关键写法

MyBatis的灵活之处在于XML和Java方法之间可以有丰富的动态SQL。车辆列表接口需要支持按编号模糊搜索、按状态精确筛选、按经纬度范围圈选，一个字都不能多查，动态SQL写出来的样子大概是：

<select id="selectBikePage" resultType="com.springbo.admin.entity.Bike"> SELECT * FROM bike <where> <if test="bikeNo != null and bikeNo != ''"> AND bike_no LIKE CONCAT('%', #{bikeNo}, '%') </if> <if test="status != null"> AND status = #{status} </if> <if test="minLng != null and maxLng != null"> AND longitude BETWEEN #{minLng} AND #{maxLng} </if> </where> ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} </select>

注意标签会自动处理第一个条件前面的AND，这个细节如果手写成WHERE 1=1的固定写法，虽然也能跑，但看着很别扭，而且语义不如清楚。另外分页使用LIMIT时，要保证参数名和@Param注解匹配，推荐使用PageHelper分页插件，不过它对多表关联查询有时会产生奇怪的count语句，我们还是倾向于手动计算offset。

5.3 本地启动完整步骤

一台干净电脑从零跑起来，只需要按下面顺序操作：

安装JDK1.8并配置JAVA_HOME。
安装MySQL，执行项目里提供的init.sql脚本，会自动创建数据库和全部表结构。
修改application.yml里的数据库账号密码（建议单独建一个库账号，不要用root）。
在项目根目录执行mvn spring-boot:run，或者打包后用java -jar target/xxx.jar启动后端。
前端项目执行npm install，再执行npm run dev，浏览器打开前端地址即可登录。

登录页面第一次进不去的常见原因，我排查下来多半是后端没起来、端口冲突或者数据库脚本没执行成功。建议后端状态看一眼日志，如果出现"Table xxx doesn't exist"，就得回去检查init.sql有没有在正确的库里执行。把这套启动顺序写成README放进项目里，能帮后来人节省很多时间。

6. 上线后遇到的高频问题与优化方向

6.1 并发更新车辆状态时的数据一致性问题

共享单车的状态更新天然是高并发的。同一辆车可能同时收到开锁请求、定位上报、后台人工改状态三种操作。如果都直接update bike set status=xxx，最后谁覆盖谁完全看运气。我们当时的做法是：所有状态变更必须通过"条件更新"，比如把"空闲"变为"骑行中"时，SQL要加上status=1这个条件。如果update影响行数为0，说明状态在读取和写入之间已经变了，业务侧就可以返回"操作冲突"。

UPDATE bike SET status = 2, lock_type = ? WHERE id = #{bikeId} AND status = 1

这个方案比引入分布式锁轻得多，因为在单机数据库场景下，条件更新的原子性由数据库本身保证，不需要额外协调者。如果以后并发量上升到需要Redis分布式锁时，再考虑演进也不迟。

6.2 慢查询和索引失效：从日志出发定位

上线一段时间后，订单表数据量涨到几百万行，某些统计接口开始出现响应超时。排查过程很有代表性：先看后端日志有没有慢SQL打印，再explain查询计划。结果发现区域订单统计用了函数运算DATE_FORMAT(start_time, '%Y-%m-%d')，导致start_time上的索引失效，只能全表扫描。解决办法是改成范围查询：

SELECT COUNT(*) FROM ride_order WHERE start_time >= '2025-01-01 00:00:00' AND start_time < '2025-01-02 00:00:00'

这种"函数包裹索引列"导致索引失效的情况，是项目中最常见的慢查询来源，没有之一。同样的坑还包括在条件里对status列做+0运算、对字符串列隐式转换等。建议把explain输出里的type字段养成习惯去盯，类型从ALL变到range或index范围才算真正用上了索引。

6.3 数据备份、权限和密码安全

管理系统积累的数据包括骑行轨迹、车辆状态历史、运维记录，这些都是运营资产。MySQL的定时全量备份至少要每天一次，备份文件放到另一台机器或对象存储，不能和数据库在同一块磁盘上。管理后台的密码不能明文存数据库，至少要用BCrypt加密，Spring Security里自带BCryptPasswordEncoder，即使没引入完整Spring Security，也可以单独用这个类做密码哈希。

还有一个安全细节是生产环境关闭后端actuator的敏感端点，避免暴露服务内部状态。很多人开发时图方便，直接暴露了/env和/beans端点，这在测试环境无所谓，一旦部署到公网等于把配置信息送给别人。在application.yml里显式配置management.endpoints.web.exposure.include=health,info是最稳的。

6.4 后续可以扩展到哪些方向

项目跑通之后，可以考虑的增强方向有：接入大屏实时监控、导出Excel报表、班次排班和运维路径规划。这些功能都能在现有表结构基础上做增量开发，不需要推翻架构。比如导出Excel，可以在后端加一个异步任务，把查询到的订单数据分批写入临时文件，再通过接口返回下载链接。前端点按钮之后轮询任务状态，用户体验会好很多。

我后来还做了一个小优化：把运维工单的处理时效统计成日报，每天早上推送给运营负责人。这个功能不复杂，就是一个定时任务加消息推送，但却是整个系统里运营同事每天必看的内容。所以做管理系统不能只盯着功能清单，要想清楚什么人会用什么功能，信息如何闭环流转，这比多写几个CRUD接口重要得多。

最后分享一点个人体会：像springbo这样的管理系统，真正难的不是技术栈里的某个API或者某个配置，而是数据模型设计得够不够贴合业务，状态流转是否严谨，异常情况下系统能不能保持数据一致。把这些问题想透，SpringBoot+Vue只是实现工具而已。如果你照着文章里的思路搭出一版能跑的系统，再回头改自己的业务需求时，会发现改SQL和加接口的道路已经铺得很顺了。