企业官网建设流程全解析

去年我们团队接了一个内部管理系统的重构需求，业务方丢过来一句话："订单车后台管理系统，功能要全，Excel订单导入必须要有。"这个系统面向物流调度和车辆订单场景，内部一直叫"订单车"，核心业务是接收各渠道的订单，再分配给车辆和司机执行，整个链路涉及订单录入、调度、状态跟踪、结算对账。我当时的第一反应是：Excel导入不就是一个上传文件、读几行数据、写进数据库的事吗？真正动手之后才发现，这个功能像一根线，把模板设计、数据校验、性能优化、容错机制、权限审计全串了一遍。这篇文章把我设计和落地这套系统的完整思路记录下来，包括功能模块规划、Excel导入的流程设计、技术选型对比，以及在真实使用中踩过的一堆坑。适合正在做后台管理系统、或者准备给老系统加导入导出功能的开发者参考。

1. "订单车"到底是个什么系统：功能定位与模块拆解

1.1 业务场景还原：谁在用这个后台

先把这个系统的边界说清楚，不然下面的所有设计都没有锚点。订单车系统不是电商那种纯C端下单后台，它是给一个做同城货运和车辆调度的业务团队用的。业务方每天从电话、微信、线下合作渠道收集订单，订单里包含货物类型、体积重量、发货地、收货地、期望用车时间、客户联系方式、运费约定这些信息。以前这些订单全靠客服手工录入Excel表格，再通过工作群发给调度员，调度员根据车辆情况手工分配。单量少的时候还能撑住，每天超过两百单就开始各种错漏：订单重复、车辆重复分配、运费对不上、客户投诉找不到原始记录。

所以要做的这个后台管理系统，本质上就是把这些散落的订单数据集中管理起来，并且让调度员在一个界面上完成"接单—派车—跟踪—完成—对账"的完整闭环。系统上线后，客服负责录入或批量导入订单，调度员在待分配列表里挑订单派给司机，司机在移动端确认接单和送达，财务在后台按订单状态做结算。这就是"功能齐全"这四个字的真正含义——不是功能数量多，而是把一条业务链路的所有环节都覆盖到。

1.2 功能清单：五大模块支撑业务闭环

我梳理需求后，把系统拆成了五个模块，每个模块对应一个明确的使用角色和业务阶段。

第一个是订单中心，这是整个系统的主表。订单列表支持按状态、时间、客户、车辆、司机多条件筛选，详情页展示完整订单信息，支持状态流转操作（待分配、已分配、执行中、已完成、已取消）和备注留痕。订单来源分为手工创建和Excel导入两种，每条订单都有唯一的订单编号和来源标记，这是后面做幂等和审计的基础。

第二个是车辆调度中心，这是订单车系统区别于普通订单系统的核心部分。调度员在待分配列表看到订单后，可以查看当前可用车辆、车辆类型匹配度、司机当前任务数，然后一键分配。分配之后订单状态自动更新，司机端能看到任务。这里我做了简单的规则引擎：重货优先分配厢式货车，大体积优先分配平板车，同区域顺路单可以合并派给同一司机。规则不复杂，但极大减少了调度员来回切换页面的次数。

第三个是客户与结算管理，维护客户档案、历史订单查询、应收账款和对账单生成。因为很多客户是月结客户，单靠Excel对账非常痛苦，这边把订单金额、附加费、折扣统一管理，到了月底可以按客户导出对账明细。

第四个是数据看板，给管理层看核心指标：今日订单量、完成率、平均响应时长、车辆利用率、取消率。数据看板不用花哨，实时性要求也不高，数据每五分钟刷新一次即可，但必须让管理层一眼看出业务趋势。

第五个是系统管理，包含用户权限、角色配置、操作日志。导入功能涉及批量写入数据，属于高风险操作，所以操作日志里必须记录"谁、什么时间、导入了哪个文件、成功多少条、失败多少条"，后面我会详细讲这个设计。

1.3 为什么要把Excel导入单独拿出来重点设计

很多人觉得导入是一个边缘功能，实际不是。我把Excel导入单独立项设计，有三个原因。

第一，订单录入效率的天花板在导入。人工录入一单平均需要一到两分钟，还要填十几个字段，容易疲劳出错。导入一次可以处理几百上千条订单，准确率反而更高，因为校验规则是代码控制的，不会因为手抖填错电话。

第二，导入是系统数据质量的入口。垃圾数据进系统之后，后续的调度、对账、统计全都会被污染。订单重复、手机号少一位、地址填反、日期格式错误，这些在导入环节不拦下来，后面要花十倍的时间去修。

第三，导入涉及的技术问题最多。文件解析要处理Excel的各种格式，数据量大要考虑内存和事务，业务校验要考虑各种边界条件，错误反馈要让人看得懂。它其实是系统里最容易翻车、也最能体现工程水平的功能点。

这个定位决定了后续所有设计方向：导入不是"把Excel读出来写进库"这么简单，而是要把它当成一个完整的数据接入管道来对待。

2. Excel订单导入的完整流程：从模板设计到数据入库

2.1 模板设计才是导入的第一个关卡

我见过很多系统做导入，上来就让用户随便拿个Excel填，然后程序按固定列索引去读。这种方案十次有八次会出问题，因为用户根本不知道你期望的格式是什么，日期填成文本、金额带单位、电话加了横线，解析全乱。

正确做法是先设计模板，把模板当成导入功能的一部分。订单车系统的模板我做了三样东西：表头sheet、数据sheet、下拉选项。

表头sheet是给用户看的说明页，写清楚每个字段的填写要求、是否必填、格式示例。数据sheet的第一行是标准表头，包括订单号、客户名称、联系电话、货物类型、货物重量（kg）、货物体积（m³）、发货地址、收货地址、期望用车时间、运费金额（元）、备注，一共十一个字段。每一列都对应用户容易理解的中文名，程序读取时按表头名映射到字段，而不是按ABC列字母去猜，这样即使用户调整了列顺序也不会读错。

下拉选项是通过Excel的数据有效性功能实现的。比如货物类型列固定为"普货、重货、冷链、易碎品"四个选项，运费结算方式固定为"现结、月结、到付"。这两个字段在调度和结算逻辑里是强关联的，如果用户自由填写，会出现"普通""B类""月结客户"这种五花八门的写法，必须用下拉框约束。模板里还内置了条件格式，必填字段留空时单元格会变红，用户在填表阶段就能发现问题，比导入后收到错误报告要高效得多。

2.2 导入链路：从上传文件到数据落库的六个环节

导入流程我设计为六个环节，每个环节都承担独立的职责，全部通过后数据才会真正入库。

第一步是上传文件。前端限制文件类型为xlsx格式，限制大小不超过20MB，超过的直接拦截。同时前端把文件名和文件大小传给后端，后端拿到文件流后先校验文件扩展名、Content-Type、文件大小，防止有人传个改后缀的exe或者特大文件把服务打挂。

第二步是表头校验。程序读取Excel第一行，和标准表头逐列比对。这一步的作用是尽早发现"用户用错模板"或者"模板被改动过"的问题。如果表头不匹配，直接返回"请使用标准模板导入"，不再往下解析。我遇到过用户把旧版本模板拿来用的情况，少了"货物体积"和"运费金额"两列，表头校验直接拦住，避免了后续字段错位。

第三步是数据格式预解析。把Excel单元格里的值转换成Java对象，这一步最容易出幺蛾子，我后面会专门讲科学计数法和日期格式两个坑。预解析阶段只做格式转换，不做业务判断，保持单一职责。

第四步是行级业务校验。逐行检查必填字段是否为空、联系电话是否为合法手机号、货物重量是否大于0、期望用车时间是否晚于当前时间、运费金额是否为合法数字。这里我把校验结果记录在内存中，不直接终止整个导入流程，保证一份文件里单条错误只报那一行，而不是一错全部回滚。

第五步是重复性检查。用"订单号 + 期望用车日期"做组合维度，在数据库查询已有订单进行比对，重复数据被标记出来跳过。这个设计在4.4节会展开说。

第六步是分批入库。全部校验通过的数据按每500条一批写入数据库，写入过程不开启大事务，每批提交一次。这个设计是为了避免一次性写入上万条导致事务日志膨胀和数据库锁等待，详细原因在后面踩坑部分说明。

2.3 错误反馈机制：别让用户在上千行里大海捞针

导入功能体验好不好，很大程度上看错误反馈做得细不细。我第一次做的版本很粗糙，校验失败就直接返回"第3行手机号格式错误，第17行重量不能为空"，用户收到这种提示只能自己去Excel里一行行数，几千行数据的文件能当场把人逼疯。

后来我把错误反馈做成了错误报告Excel。导入完成后，如果存在失败数据，系统会生成一个错误文件，保留原始数据的所有列，并在最后加一列"错误原因"，同时标注原始Excel行号。用户可以直接下载错误文件，看到红字提示，改完后再重新上传。错误文件里我特意保留了原始业务字段，比如订单号、客户名称，这样用户不用再去翻原Excel对是哪一行。

为了这个功能，我在解析阶段的时候给每条数据都记录了一个rowIndex，这个索引不是数据库自增ID，而是Excel里的实际行号。这样一张错误报告可以直接告诉用户"问题出在Excel的第28行"，比让用户自己找高效太多。这个细节花了不到半小时实现，但业务方反馈是所有功能里"最像人做的"一个。

3. 技术选型为什么是EasyExcel + 服务端导入

3.1 POI、EasyExcel、前端解析三条路对比

订单车系统在技术选型的时候，导入功能其实有三条路线可以走。

第一条是直接用Apache POI。POI功能最全，读写Word、Excel、PPT都能做，但内存占用是出了名的高，它读取大文件时会直接把整个工作簿加载到内存，一个20MB的Excel有可能会吃掉1GB以上的堆内存。我们系统部署的服务器内存只有4GB，留给业务服务的堆内存大概2GB，POI一旦处理稍大的文件，Tomcat进程很容易直接OOM。

第二条是用阿里开源的EasyExcel。它本质上是封装了POI的底层解析能力，但采用了SAX模式的事件驱动解析，读文件时不会把整个工作簿加载进内存，而是逐行解析、逐行回调。同样的20MB文件，EasyExcel的内存占用可能只有POI的十分之一。API设计也友好，用注解就能映射字段，对业务开发来说效率高很多。

第三条是前端解析方案，比如用SheetJS在浏览器里把Excel解析成JSON，再把JSON POST给后端。这条路在极轻量场景下确实方便，几十行数据、字段简单、不需要严格校验，前端一把梭也行。但订单车系统的导入涉及复杂的业务校验、重复检查、与大事务相关的操作，这些逻辑放在前端既不安全也没法复用，而且浏览器处理大文件同样有崩溃风险。

对比结果清清楚楚：EasyExcel + 服务端导入是唯一兼顾性能、安全和开发效率的方案。这个选型在后来的实测中也得到了验证，单次导入5000行数据，接口耗时稳定在3秒左右，内存峰值不到200MB。

3.2 导入接口的关键实现：EasyExcel监听器的正确打开方式

EasyExcel的核心使用方式是实现一个AnalysisEventListener，在invoke回调里逐行接收解析出来的数据。我一开始犯过一个思路上的错误，就是在invoke里直接去查数据库做重复校验，结果五千行数据触发了五千次数据库查询，接口耗时直接飙到20秒以上。后来改成用批量缓存和预查询，性能才正常。

这里给出一个核心代码骨架，能说明我的实现思路：

public class OrderImportListener extends AnalysisEventListener<OrderExcelRow> { private static final int BATCH_SIZE = 500; private final List<OrderExcelRow> batch = new ArrayList<>(); private final OrderImportService importService; private final ImportContext context; public OrderImportListener(OrderImportService importService, ImportContext context) { this.importService = importService; this.context = context; } @Override public void invoke(OrderExcelRow row, AnalysisContext analysisContext) { // 1. 先记录原始行号 row.setRowIndex(analysisContext.readRowHolder().getRowIndex() + 1); // 2. 格式转换：处理单元格的值，Excel原始值可能是各种格式 importService.convertAndValidateRow(row, context); // 3. 加入批处理列表，攒够一批再处理 batch.add(row); if (batch.size() >= BATCH_SIZE) { importService.processBatch(batch, context); batch.clear(); } } @Override public void doAfterAllAnalysed(AnalysisContext analysisContext) { if (!batch.isEmpty()) { importService.processBatch(batch, context); } importService.finish(context); } }

这个监听器有两个设计要点。第一，processBatch方法负责业务校验、重复检查和批量插入，所有数据库操作都放在这一层，而不是invoke里。invoke只做内存缓存，攒够500条再一次性交给processBatch处理。第二，context对象贯穿整个导入过程，里面记录成功条数、失败明细、异常信息，最终由finish方法统一生成导入结果和错误报告。

这里我还要提一个实际业务中容易忽略的环节：不同渠道的Excel模板可能字段位置不一样。订单车系统对接了三个不同来源的Excel，表头名字各不相同，有的叫"收货人电话"，有的就叫"联系电话"。我的做法是在表头校验阶段做一次字段名归一化映射，把不同叫法映射到统一的内部字段，这样即便用户用了非标准模板，只要语义一致就能导入成功，而不是死板地要求必须用系统模板。

3.3 批量插入策略与事务边界：关键的性能取舍

数据库写入这一环，我经历过从慢到快的完整过程，值得单独说一下。

第一次实现时，我在doAfterAllAnalysed里调用一个方法把全部数据传给MyBatis-Plus的saveBatch，由它生成一条insert批量插入。问题在于saveBatch默认是分批提交的，但它和解析流程之间没有更好的协调，数据量过万时接口总耗时依然很长，而且如果中间某条数据触发了唯一键冲突，整个保存会抛异常，之前已经提交的批次和未提交的数据状态就变得很混乱。

后来我把事务控制整理成了两条清晰的原则。

第一条原则是只对"真正需要原子性的操作"开启事务。订单车系统的导入性能要求是：单次最多2万行，允许部分失败，但必须保证失败行不写入。因此正确做法是每条记录先做完整的校验和去重，只有单条数据本身合法、不重复，才执行插入，插入失败就单独记录该行异常，绝不因为这行失败而回滚其他几千行。这样单条数据是原子的，整体导入不是。

第二条原则是控制单批次大小。经过实测，500条一批是比较合适的值，太小则数据库交互次数过多，太大则单条SQL语句过长、锁等待概率增大。数据库连接池配置了20个连接，多个用户同时导入时也不会把连接池打满。

调用入口处我加了@Transactional注解吗？没有。大数据量导入场景下最忌讳的就是在整个入口加一个大事务，因为一个事务从第一条插入到最后一共持续几十秒，期间数据库连接一直被占用，其他业务操作全部被阻塞，行锁也会卡住调度的并发任务。我最后采用的是"无大事务 + 小批量自提交"模式，同时配合数据库层的唯一索引兜底，保证并发下也不会产生脏数据。

4. 实测中踩过的一串坑：导入功能最容易翻车的5个细节

4.1 科学计数法：Excel里的"订单号"怎么变成了1.23E+10

这个坑在第一次联调的时候就炸了。业务方拿了一份真实订单Excel来测试，导入后数据库里的订单号变成了"1.23570E+10"这种科学计数法格式。问题根因是Excel内部把纯数字列当成了数值类型，而订单号足足有11位，超过Excel默认的数值精度，显示出来就是科学计数法，EasyExcel读到的值自然也是经过转换后的数值。

这个问题的本质是数据精度在不同表示之间转换的损失，在订单号、身份证号、手机号这类长数字字段上特别容易出现。解决方案是在模板设计阶段，把这类字段的单元格格式显式设为"文本"，同时在EasyExcel的@ExcelProperty注解里用String类型去接收，并且增加解析配置强制按字符串读取。

我第一版只处理了模板，后来发现用户经常把模板里的订单号列自己改成数值格式，或者直接从别的系统导出的原始表格复制粘贴，格式还是坏的。所以又在程序里加了一层兜底：如果读取到的值是Number类型，先转成BigDecimal，再用stripTrailingZeros和toPlainString去掉科学计数法后缀，还原成完整数字字符串。从此再没出现订单号变E的情况。

4.2 日期格式和空行：用户不会按你定义的格式填表

期望用车时间这个字段是重灾区。模板里明明写了"格式：2024-08-15 14:00:00"，但用户实际填出来的有"2024/8/15 14:00"、有"2024年8月15日"、还有只填"8月15"不带年份的。EasyExcel默认的日期解析只认标准格式，遇到这些变体直接解析失败或者解析成错误的值。

我最终实现了一个多格式日期解析器，按优先级依次尝试十种常见格式，包括标准时间、毫秒时间戳、Excel序列日期值、带中文年月日的字符串等。还有一个小细节是Excel有时会把日期存储为序列值，比如45223表示的是2023-11-01之前的某个日期，需要调用EasyExcel的DateUtil去转换。日期解析器这块代码看起来不起眼，但实际是业务方使用满意度最高的部分，因为导入再也不用因为日期格式被卡住。

空行问题同样隐蔽。用户可能为了排版美观，在数据行之间留了几行空行，或者删除了数据但留下了Excel格式残留。EasyExcel默认不会自动跳过空行，监听器照样会收到一个全字段为null的对象，如果不加过滤，这种空对象会在必填校验环节报一堆错误。我的做法是在invoke入口处先判断关键字段是否全部为null，是就直接return。

4.3 内存和事务：2万行数据导入时接口直接卡死

有一个版本上线后，生产环境出现了导入超过1万行时接口卡死的情况。排查后发现是POI内存问题——当时某个解析分支还在用老代码读取文件，导致堆内存飙到极限，GC频繁触发，服务几乎失去响应。后来统一替换成EasyExcel的流式解析，这个问题才彻底解决。

这让我意识到导入性能问题必须在一开始就做好压测。我用JMeter对2万行数据的导入接口做了压测，重点关注两个指标：接口P95耗时和堆内存峰值。压测结果给了我三个结论：第一，解析过程中内存消耗平稳，说明EasyExcel的流式解析确实有效；第二，批量插入500条/批时，总耗时比1000条/批低10%左右，因此选择500作为固定批次大小；第三，并发两个导入任务时，数据库连接池占用正常，不会拖垮其他业务查询。

另外一个容易被忽视的点是，导入接口的HTTP请求超时时间需要单独调大。Nginx默认的60秒超时在2万行数据导入时是不够的，我把它调整到180秒，并且在前端提示用户"文件较大时请稍候，不要重复点击"。用户心理预期一旦管理好，反馈的负面情绪会大幅减少。

4.4 重复导入与幂等设计：同一天同一批订单被导了两次

重复导入是业务方最担心的问题，因为一旦重复，同一订单会被派两次车，产生严重客诉。系统刚上线时，就有客服在导入时手抖双击了提交按钮，结果同一份订单Excel被导了两遍，调度员看到同一客户同一收货地址出现了两条订单，还以为是客户下单两次。

解决重复导入的核心是幂等设计，我在两个层面做了防御。

第一个层面是数据库唯一索引。在订单表上创建"订单编号 + 期望用车日期"的联合唯一索引，这是最后一道防线，数据库层面直接拒绝重复数据，无论如何都不会写入两条相同订单。唯一索引字段的选取要非常谨慎，订单车系统的订单编号在不同渠道来源中可能是重复的，所以必须加上日期维度来区分。

第二个层面是导入前的内存去重。同一份文件内有重复行时，不依赖数据库报错，而是在校验阶段就尝试放入一个HashMap，键为"订单号 + 期望用车日期"，检查发现重复就直接标记错误。同时，针对双击提交的场景，我在前端上传按钮加了loading状态，提交后立即禁用，并且在服务端入口做了短时间窗口的重复文件Sha1校验，连续收到相同内容的文件直接拒绝。

4.5 文件类型与大小校验：安全边界不能靠前端

前端限制文件类型很容易被绕过，直接Postman调接口就能传任意文件。所以服务端必须做双重校验。

文件扩展名校验是最基本的，只允许xlsx，不允许xls。为什么不用xls？因为EasyExcel的高性能模式是为xlsx设计的，xls解析性能差很多，而且业务方的Excel基本都是新版格式，不需要兼容老版本。

Content-Type校验顶多算一种辅助手段，因为浏览器上传文件的Content-Type不可靠，同一个xlsx可能是application/vnd.openxmlformats-officedocument.spreadsheetml.sheet，也可能是application/octet-stream。真正可靠的校验是解析文件内部的ZIP结构，xlsx本质上是一个ZIP压缩包，可以通过检查压缩包内是否包含xl/workbook.xml来判断是不是真的xlsx。这个方法在前端绕过的场景下也能准确识别。

文件大小限制我设置为20MB，这个数值不是随手拍的。按照订单车系统的业务字段数量和平均字段长度，20MB大约能容纳8万行订单，远超正常单次导入量。超过这个值直接拒绝，实际上保护的是服务端内存和解析时间，避免有人恶意上传超大文件导致服务不可用。

5. 导入之外的设计：订单车系统的其他关键细节

5.1 订单状态流转：别让订单在系统里变成"死数据"

Excel导入只是订单生命周期的起点，订单进入系统之后的状态设计同样影响交付质量。订单车系统的订单状态我定义为六个：待分配、已分配、执行中、已完成、已取消、异常关闭。

这里的核心设计原则是不能让订单卡在中间状态出不来。比如已分配状态下，如果司机接了单但临时取消，订单不能直接跳回待分配，而是要先进入"待重新分配"的过渡阶段，由调度员确认后手动重新派车。这个"重新分配"动作有独立的日志记录，方便追踪每一次派车变更的原因。已完成状态的订单不允许直接删除或编辑关键字段，只能通过"订单更正"流程处理，保证对账数据的可信度。

导入产生的订单默认进入待分配状态，如果有特殊标识（如加急件、冷链件）则在导入时用标签字段标记，调度列表里高亮展示。这个设计和导入功能配合得很好，数据从进入系统那一刻起就带着完整的状态信息，调度员不用再去问客服"这单是不是加急"。

5.2 车辆调度与订单匹配：核心业务逻辑的简化实现

车辆调度模块的匹配逻辑不复杂，但一开始的设计有个明显问题：调度员需要把订单和车辆一一手动关联，每天几百个订单录入后，光派车就要花两三个小时。后来我加了一个半自动匹配功能：系统先按规则给出推荐调度方案，调度员确认后批量生效。

规则实现分三步走。第一步根据货物的重量和体积，筛选出载重和容积都满足要求的车型，排除掉所有不匹配车辆。第二步根据发货地址所在区域和车辆当前所在位置，计算出预计到达时间，过滤掉无法在期望用车时间前到达的车辆。第三步在同一区域内优先级最高的是空闲车辆，其次是即将完成任务的车辆，最后是正在执行但可以拼单的车辆。

调度结果展示时，我会同时展示推荐方案和备选车辆列表，调度员需要看一眼前者，后者用来处理特殊情况，比如客户要求指定司机。这块逻辑我在最初版本里做复杂了，引入了完整的约束规划算法，结果数据量根本达不到发挥算法优势的程度，后来简化为上述规则引擎，反而更稳定、更容易维护。

5.3 导入日志与操作审计：出了问题知道找谁

导入功能会上传大量订单数据，直接影响核心业务，所以审计日志是刚需。我设计了一张导入记录表，每次导入成功或失败都写入一条完整记录，包括导入人、导入时间、文件名、文件Sha1哈希、总行数、成功行数、失败行数、失败原因摘要、错误报告下载地址。

为什么要有文件哈希？因为后续如果发现导入的某批数据有问题，可以通过哈希找到原始文件，重新下载并核验。为什么要记录失败原因摘要？因为运维排查时不需要重新上传文件就能快速定位问题类型，比如"手机号格式错误占比80%"这种信息可以直接告诉我们模板是否需要优化。

操作日志模块同时记录了用户在系统里的所有关键操作，包括状态流转、派车计划变更、删除订单等。日志不是简单的一句话文本，而是结构化的操作记录：操作对象类型、对象ID、操作前数据、操作后数据、操作人、操作时间。这样审计时可以直接还原一条订单从导入到完成的全轨迹，业务方在争议处理时非常依赖这个功能。

5.4 一点个人经验：先让业务跑起来，再谈优化

最后分享一个我的体会。订单车系统从第一个能跑的版本到上面说的稳定版本，大概经历了两轮迭代。第一轮上线只做了手工录入和订单管理，Excel导入是第二轮才加的。很多团队容易犯的错是一开始就追求大而全，花一个月把导入、调度、看板全部做完，结果上线后业务反馈说"我只需要先把订单管起来"。分阶段上线的好处是每轮都有明确的核心反馈，导入功能的很多细节比如错误报告、下拉选项、重复检查，都是业务方在实际用了之后提出的改进点，而不是我闷头设计的。

如果你也在做类似的后台系统，我的建议是先把核心链路跑通——哪怕导入只支持标准模板、哪怕调度全靠手动，先让使用者有系统可用。有了真实数据和使用习惯之后，再逐步优化导入的容错性、调度的智能性。这样每一步都有据可依，不会做出看起来功能十足、实际用起来浑身别扭的系统。

做这套系统给我最大的教训是，Excel导入这种"小功能"恰恰是最能体现系统成熟度的地方。模板设计得细心一点，错误反馈做得人性化一点，幂等和日志考虑得周全一点，用户在导入数据时的信任感就会完全不一样。订单车系统上线之后，业务方最常夸的不是界面多好看、看板多炫，而是"导入订单真的省心"。这句话在后台管理系统里，算是很高评价了。