基于ThinkPHP的企业进销存系统开发：从库存流水到权限控制的完整实践

1. 项目背景与核心目标

1.1 为什么选择ThinkPHP做企业进销存

我接手这个项目的时候，对方是一家做建材贸易的中小公司，SKU大概有三千多个，每天出入库单据量在两百张左右。原来他们用的是Excel加纸质单据，仓库盘点一次要折腾两天，采购部和销售部的库存数据经常对不上——销售说某型号还有货，仓库说早发完了，这种扯皮每天都要来几轮。

所以要上一套企业进销存管理系统，核心诉求其实非常朴素：把商品的入库、出库、库存余量、往来账目管清楚，让老板打开电脑就能知道仓库里还剩多少货、哪些货快卖完了、这个月赚了多少。技术选型上，考虑到团队后续维护成本和开发效率，最终敲定ThinkPHP。这套框架在国内中小企业项目里的普及率确实高，中文文档全，网上踩坑案例也多，社区生态成熟。最重要的是它的上手曲线比较平缓，招人好招，后续做二次开发不至于被某个人绑死。

ThinkPHP做进销存这种典型的管理系统，开发效率真的没得说。框架自带的ORM、验证器、中间件、缓存机制，覆盖了这类业务系统绝大多数的基础需求。从立项到第一版可演示的版本，我们大概用了三周时间，这个速度在和客户对需求、改界面的反复拉扯中非常关键——因为这类系统的需求永远在变，不快速出雏形，后面根本推不动。

1.2 系统到底要管哪些事

进销存系统，字面上是进货、销售、库存三件事，但落到实际业务里，牵扯的东西比想象中多得多。我从需求梳理阶段就把功能模块拆成了几个核心块：

基础资料管理：商品信息、分类、计量单位、供应商、客户、仓库。这些是整个系统的地基，地基不稳后面全是坑。

采购管理：从采购下单到入库的过程，核心是采购单和入库单的关联，以及供货商往来账目。

销售管理：销售订单、出库单、退货单，核心是出库时库存的准确扣减，以及客户账期管理。

库存管理：实时库存、库存流水、库存预警、盘点、调拨。

统计报表：采购统计、销售统计、库存汇总、毛利分析、供应商/客户对账单。

系统权限：不同角色的人看到不同的菜单和数据范围，不能让仓库的人看到采购成本，这是很敏感的事情。

系统设置：用户管理、角色权限、操作日志、基础参数配置。

这套系统本质上就是一个围绕"商品在仓库里的数量变化"展开的数据管理系统。所有模块都是在回答几个问题：货从哪来（采购）、货到哪去（销售）、现在还剩多少（库存）、每笔钱怎么算（账务）。把这个核心逻辑想清楚了，后面的表结构设计、代码开发都会顺很多。

2. 技术方案与数据库设计

2.1 ThinkPHP版本选型与环境搭建

我们用的是ThinkPHP 6.0。选这个版本主要是考虑长期维护成本——6.0是官方主推的长期支持版本，Composer生态适配度高，PHP版本要求也合理（PHP >= 7.2.5，实际我们跑在PHP 8.0上）。对比一下ThinkPHP 5.1和6.0，最大的区别是底层架构完全重构了，6.0摆脱了5.x时代的很多历史包袱，依赖注入、容器、中间件都更规范。

搭环境的时候有个非常典型的坑要先说一下：ThinkPHP 6.0默认不安装JSON扩展相关的依赖包。如果你用Composer安装完框架之后，执行php think run直接报错，提示找不到json_encode函数之类的，多半就是PHP环境里的ext-json扩展没有启用。这个扩展在PHP 8.0里默认是内置的，但在部分Linux发行版（尤其是用apt装PHP的环境）里需要单独安装。如果你用的是宝塔面板，直接在PHP设置里把json扩展勾上；如果是手动编译的PHP，需要确认--enable-json参数。ThinkPHP的Composer依赖里明确要求了ext-json，所以这类问题其实在composer install的时候就会报出来，但很多人在Windows本地环境装的时候没注意，上了服务器才踩坑。

环境清单参考如下：

PHP：7.4或8.0（推荐8.0，性能更好）

Web服务器：Nginx + PHP-FPM

数据库：MySQL 5.7+ 或 MariaDB 10.3+

Cache：Redis（用于会话管理和高频缓存）

Composer：2.x

2.2 数据库表结构设计：进销存的命脉

这部分是我在整个项目里花时间最多的。进销存系统的数据库设计如果出了问题，后面所有业务代码都会写得很别扭。我的设计原则是"业务单据与库存流水分离，余额字段与流水记录并存"。

核心表结构如下：

商品表（product）：id、category_id、product_no、name、spec、unit、purchase_price、sale_price、stock_warning、status。注意这里不直接存库存数量，库存是算出来的，不能冗余在商品表里，否则并发更新会出现严重的脏数据。

仓库表（warehouse）：id、name、address、manager。一个企业可能有多个仓库，每个商品在不同仓库的库存需要分开统计。

库存表（inventory）：id、product_id、warehouse_id、quantity、locked_quantity。这里只存当前库存数，通过唯一索引（product_id + warehouse_id）保证一个商品在一个仓库只有一条记录。

库存流水表（inventory_log）：id、product_id、warehouse_id、change_type（入库/出库/盘点调整/调拨出/调拨入等）、change_qty、before_qty、after_qty、related_id、user_id、create_time。这张表是进销存系统的灵魂，每一笔库存变动都要记录，它是所有报表的数据源，也是排查对不上账的关键。

采购入库单表（purchase_order / purchase_order_item）：主表存单号、供应商、仓库、总额、状态、审核人、审核时间等；子表存商品、数量、单价、金额。

销售出库单表（sale_order / sale_order_item）：结构类似采购单，关联客户信息。

其他辅助表：supplier（供应商）、customer（客户）、user（用户）、role（角色）、permission（权限）、operation_log（操作日志）。

我解释一下为什么要单独搞一张库存流水表。很多新手做进销存，习惯直接在商品表里更新库存字段，入库就加、出库就减。这样做的问题是：你无法回答"这批货是什么时候进的""那批货是哪天出掉的"这类问题，也无法做批次追溯。一旦发生业务纠纷或者数据对不上，没有流水等于没有证据。库存流水表的存在，让每一笔库存变动的来龙去脉都有据可查。

另外一个很重要的设计是库存锁定。这个概念在电商系统里特别常见，但在传统进销存里很多人会忽略。比如销售订单创建了但还没出库，这时候如果不锁定库存，仓管看着订单有货就去出，结果另外一单也在抢这批货，实际库存不够了。所以在库存表里我加了一个locked_quantity字段，下单时锁定，出库时解锁并实际扣减。这个字段在业务量不大的情况下可以不做，但一旦有多个销售员同时开单，没有锁定机制就会出乱子。

2.3 权限设计与RBAC落地

进销存系统涉及钱和货，权限控制必须做细。我们用的是基于角色的访问控制（RBAC），ThinkPHP里没有内置完整的权限组件，我直接自己写了一个轻量级的权限校验中间件。

角色分四类：

• 超管：拥有所有权限，一般就老板或系统管理员
• 采购：只能操作采购模块、供应商管理、采购报表
• 销售：只能操作销售模块、客户管理、销售报表
• 仓管：只能操作出入库、盘点、库存查询，看不到采购成本和销售价格

实现上，登录后把当前用户的权限列表存到Session里，权限校验中间件对每个请求做拦截判断。比如仓管角色访问/sell/order/create这个路由时，中间件检查权限标识sell/order/create是否在用户权限列表中，不在就直接拒绝。

数据范围的控制也需要注意。同样是销售角色，不同的人可能只负责不同区域的客户。我在权限表之外额外加了一个数据权限字段，限定用户能看到的客户范围。这个在需求里可能不是一开始就有的，但用户用起来之后很快就会提出来。

3. 核心功能模块的实操实现

3.1 商品管理与库存实时更新

商品管理是进销存的地基，所有单据最终都要落到商品上。商品编码的设计要提前想好，不建议直接用自增ID当商品编号对外展示，因为一旦有商品删除了，ID断了，你开单的时候对不上。我自己用的是一个规则编码，比如SP-加四位分类码加四位流水号。这个编码在商品录入时自动生成，可以手工修改，但保存时校验唯一性。

商品录入时要处理的关键字段包括：商品名称、规格型号、计量单位、采购价、销售价、预警库存量。这里有个容易忽略的点：同一个商品可能出现在不同仓库，但商品本身的采购价和销售价是全公司统一的。如果要支持不同采购批次不同价格，需要引入批次价格的概念，这个在简单版本里先不做，用商品表里的统一价格就行。

库存实时更新这一块，我用的是ThinkPHP的模型事件或者Service层统一封装库存变更方法。关键代码思路如下：

public function changeStock($productId, $warehouseId, $changeType, $qty, $relatedId) { DB::startTrans(); try { $inventory = Inventory::where('product_id', $productId) ->where('warehouse_id', $warehouseId) ->lock(true) ->find();

if (!$inventory) { $inventory = new Inventory(); $inventory->product_id = $productId; $inventory->warehouse_id = $warehouseId; $inventory->quantity = 0; $inventory->locked_quantity = 0; } $beforeQty = $inventory->quantity; $afterQty = $beforeQty + $qty; // 出库时$qty为负数 if ($afterQty < 0) { throw new \Exception('库存不足'); } $inventory->quantity = $afterQty; $inventory->save(); // 记录流水 InventoryLog::create([ 'product_id' => $productId, 'warehouse_id' => $warehouseId, 'change_type' => $changeType, 'change_qty' => $qty, 'before_qty' => $beforeQty, 'after_qty' => $afterQty, 'related_id' => $relatedId, 'user_id' => session('user_id'), ]); DB::commit(); } catch (\Exception $e) { DB::rollback(); throw $e; }

}

这个方法用了数据库行锁（lock(true)），保证并发情况下库存读改写是原子操作。所有涉及库存变动的业务（入库、出库、盘点、调拨）都统一走这个方法，而不是在各自模块里直接改库存字段。这是整个系统最关键的约定之一，我把这个约定写进了项目开发规范里。

3.2 采购入库流程与事务处理

采购入库的完整业务链路是：创建采购单 -> 提交审核 -> 审核通过 -> 关联入库单 -> 实物到货后确认入库 -> 库存增加 -> 生成应付款记录。

实际开发中我遇到的第一个问题是：采购单和入库单要不要分开？我的答案是必须分开。原因很简单：采购单是"计划"，入库单是"执行"，两者时间不同步。你今天下了采购单，供应商可能三天后才送货，中间可能只送一部分货。如果采购单直接改库存，库存数据就完全失真了。

所以采购单的状态机是这样的：待审核、已审核、部分入库、已完成、已取消。入库操作产生独立的入库单，入库时检查该采购单已入库数量+本次入库数量是否大于采购数量，超出就拦截提示。

事务处理是这里最容易出bug的地方。一个入库单的操作要同时改多个表：入库单主表、入库单子表、库存表、库存流水表、采购单的已入库数量、供应商的应付账款。任何一个环节失败，所有数据都要回滚。ThinkPHP的事务嵌套有个坑要特别注意：如果在事务里调用了其他方法，而这个方法内部又开启了新事务，可能会导致锁的持有时间不可控甚至死锁。我的做法是统一封装一个InventoryService::inbound()方法，把库存变更逻辑和单据逻辑在同一个事务里完成，其他业务模块不要自己搞DB::startTrans。

审核流程也很重要。我遇到过业务人员点了入库之后发现单据有误，直接在数据库里改数据的情况，这是最危险的操作。所以在设计上，审核通过的入库单不允许编辑和删除，只能做红冲（生成一张负数入库单来冲抵）。这个红冲逻辑用到了库存流水表的change_type字段，类型为"红冲入库"，数量为负。这样做的好处是所有操作都留痕，不会出现账面上有一笔负库存却查不到来龙去脉的情况。

3.3 销售出库与超卖防护

销售出库的逻辑和采购入库对称，但有一个关键的差异：销售出库必须处理超卖问题。前面说了，可以用行锁加数量判断来阻止超卖，但还有更精细的做法：库存锁定。

销售开单的完整流程应该是：创建销售单 -> 库存锁定 -> 审核 -> 出库（解锁并扣减）-> 生成应收账款。这里库存锁定非常关键，它保证了两个销售员同时开单时，不会出现两个订单都显示"有货"，结果实际库存只够一单的情况。

锁定的实现方式是在库存表里加locked_quantity字段。锁定操作在创建销售单时调用：

public function lockStock($productId, $warehouseId, $qty) { $affected = Inventory::where('product_id', $productId) ->where('warehouse_id', $warehouseId) ->whereRaw('quantity - locked_quantity >= ' . intval($qty)) ->update([ 'locked_quantity' => DB::raw('locked_quantity + ' . intval($qty)) ]);

if (!$affected) { throw new \Exception('可售库存不足'); }

}

这里的关键是用whereRaw条件直接拼进UPDATE语句里，通过数据库层面保证"可售库存（quantity - locked_quantity）>= 本次锁定数量"这个条件是原子成立的。如果这条UPDATE影响行数为0，说明可售库存不足，直接抛异常。这比先SELECT再UPDATE的方式靠谱得多，彻底避免了并发下单时两个请求都读到同一个可用库存数字的问题。

出库时要做两件事：把locked_quantity减掉对应数量，把quantity减掉对应数量。注意这里要先解锁再扣减还是先扣减再解锁？我的经验是在同一个事务里完成，并且用一条UPDATE语句搞定：

Inventory::where('product_id', $productId) ->where('warehouse_id', $warehouseId) ->where('locked_quantity', '>=', $qty) ->update([ 'quantity' => DB::raw('quantity - ' . intval($qty)), 'locked_quantity' => DB::raw('locked_quantity - ' . intval($qty)) ]);

如果UPDATE影响行数为0，说明锁定的库存数量不对，说明业务逻辑有bug或者数据被人为改过，要报警排查。这个细节看起来很简单，但它是销售出库数据准确性的最后一道防线。

3.4 库存预警与盘点差异处理

库存预警是老板天天看的功能。实现思路不复杂：每次库存变动时，检查变动后的库存数量是否低于商品表里设置的stock_warning值，如果低于就插入一条预警记录。也可以做定时任务扫描，但我更推荐实时判断，因为进销存的库存变动量不大，实时判断的开销完全可以接受。

预警记录表设计：id、product_id、warehouse_id、current_qty、warning_qty、status（未处理/已处理）、create_time。当库存高于预警值（比如补货到货后），自动把未处理状态的预警记录标记为已处理。

盘点这里我经历了一次比较大的教训。第一次做盘点的逻辑是：盘点单提交后，直接把库存表的数量改为盘点数量。结果有个仓库的同事在盘点录入过程中，另一边的销售出库单也在正常出库，两边的数据就冲突了——盘点提交时把当时实际已经出掉的那部分库存又加回来了。后面我改成了"盘点时锁定"策略：创建盘点单时，对涉及的库存记录加锁，盘点期间禁止该仓库这部分商品的出入库操作。虽然对业务流程有一定影响，但相比数据错乱，短暂的锁定是可以接受的。

盘点差异的处理也需要谨慎。盘点后实际数量比账面少，形成盘亏，这部分差异不能直接减库存了事，需要走审批流程，确认是损耗、丢失还是录入错误。所以盘点单的状态机是：盘点中、待审批、已审批、已驳回。只有审批通过的盘点单才会真正更新库存并记录流水，流水类型为"盘盈"或"盘亏"。

4. 开发中的关键细节与踩坑记录

4.1 ThinkPHP输入过滤与参数处理

这里要单独讲一下thinkphp input /d 相关的坑。经常有群友问TP5/TP6里input('param.id/d')这种写法是啥意思。简单说，/d是ThinkPHP输入变量的强制转换规则，把获取到的值强制转换为整型。同理还有/s（字符串）、/f（浮点数）、/a（数组）。在进销存系统里，几乎所有ID参数都要用这种过滤方式，避免恶意构造参数导致SQL注入或越权访问。

但问题来了：ThinkPHP 6.0里，input('id/d')的写法在Request对象的某些场景下会失效，尤其在路由参数获取时，->param('id/d')的写法更可靠。而且依赖注入方式从think\facade\Request改成了think\Request，这跟5.x不一样。如果你是从TP5.1迁移过来的代码，不修改这些细节，经常会遇到"明明配置了过滤规则却不起作用"的怪问题。

我自己的项目里统一封装了一个BaseController，对所有请求参数做统一过滤，核心逻辑如下：

$params = $this->request->param(); // 对整型参数做强制转换 if (isset($params['id'])) { $params['id'] = intval($params['id']); } if (isset($params['page'])) { $params['page'] = max(1, intval($params['page'])); } if (isset($params['limit'])) { $params['limit'] = min(100, intval($params['limit'])); }

为什么强调这个？因为进销存系统的很多删除、编辑操作都是根据ID来的，如果ID参数能被人为构造，就可能出现普通员工删除别人创建的采购单这类越权操作。虽然我们还做了权限校验，但参数的合法性校验是安全的第一道防线。

4.2 列表分页与查询优化

进销存系统的列表页非常考验查询优化。采购单列表、销售单列表、库存流水列表，这些表的数据量会随着业务增长越来越大。库存流水表一年可能积累几十万条记录，如果不做针对性的查询优化，列表页会越开越慢。

我一开始用ThinkPHP的paginate分页，简单好用，但性能问题很快暴露了。原因在于关联查询：列表页需要显示商品的名称、分类名称、供应商名称，而这些信息都在关联表里。用ORM默认的关联预加载（with方法）可以解决大部分N+1问题。但更复杂的场景，比如按日期范围、商品编码、供应商名称、单据状态等多条件组合筛选时，预先加载就不够用了。

我的优化思路是：列表查询直接走Db查询构造器，用join关联需要的字段，而不是用ORM的模型关联。虽然ORM更优雅，但join在大列表场景下性能确实更好，尤其是在MySQL优化器对LEFT JOIN的支持比较成熟的情况下。分页用limit手动分页，总记录数用单独的count查询。关键索引也要建好，我的索引策略是：

• inventory_log表：(product_id, change_type, create_time)
• inventory表：(product_id, warehouse_id) 唯一索引
• purchase_order表：(order_no) 唯一索引，(status, create_time)
• sale_order表：(order_no) 唯一索引，(status, create_time)

添加索引之后，月数据量五万条左右的流水，分页查询都能稳定在几十毫秒内返回。

4.3 ext-json扩展与Composer依赖坑

这个坑我在前面环境搭建时提了一嘴，但值得单独展开。有次我在一台闲置的服务器上部署项目，PHP版本是7.4，运行php think run直接报错：

Call to undefined function think\facade\json_encode()

这个报错非常误导人，看起来像是框架的问题，其实是因为PHP环境没有启用json扩展。ThinkPHP的composer.json里，"require"字段明确写了"ext-json": "*"。在composer install时如果扩展缺失，Composer会直接拒绝安装依赖。但如果你是在一台已经装好依赖的机器上把代码拷过去的，composer不会在运行时报错，直到执行到json_encode才暴雷。

解决办法看你的PHP是哪里装的：

• 宝塔面板：在PHP设置 -> 安装扩展里勾选json，重载PHP-FPM
• apt/yum安装的PHP：执行apt install php-json或yum install php-json
• 源码编译：编译时加上--enable-json（PHP 8.0以后json是内置核心扩展，不需要额外启用）

这里要注意PHP 8.0和PHP 7.4的差异。PHP 8.0已经把json扩展列为内置扩展，默认启用，所以一般不会遇到这个问题。如果是跑在PHP 7.4上，一定要检查。

还有一个和Composer相关的坑是：如果你在项目里用了Redis缓存，别忘了安装ext-redis扩展。有次我在本地测试一切正常，上服务器后登录功能老是报错，排查半天发现是Session驱动配置了Redis，但服务器上没装Redis扩展。这类环境依赖问题，我的建议是在项目部署文档里明确写清楚环境要求清单，挨个检查，别省事。

4.4 表格导入导出的效率问题

进销存系统免不了要做Excel导入导出。商品批量导入、库存盘点单导入、销售单导出，这些操作在数据量大时极容易超时。我一开始用了PhpSpreadsheet库，处理几千行数据的导入需要好几秒，导出一万条记录直接内存爆炸。

优化方案分两步。第一步，导出时不要一次性把所有数据都加载到内存里，而是分批从数据库取、分批写入文件。PhpSpreadsheet支持设置单元格值后立即保存到临时文件，但更简单的方案是直接输出CSV文件。虽然Excel打开CSV可能会乱码，但前置加一个BOM头（\xEF\xBB\xBF）就能解决。性能方面，CSV导出十万行数据也就一两秒。

第二步，导入时不要逐行INSERT，而是积累到一定量（比如500条）后批量写入。这个方法配合事务，导入效率提升非常明显。另外导入前先读取Excel文件把数据全部转成数组，再进行数据校验，校验通过后再入库。这里的校验包括商品编码是否存在、必填字段是否为空、数量是否为数字等。校验失败的记录要明确提示是第几行出了问题，方便用户修正。

5. 典型问题排查技巧与心得

5.1 常见问题速查表

我整理了项目上线后最常遇到的几类问题，做成一个速查表，排查思路和解决方案都在里面：

5.2 一次真实的库存对账事故

项目上线第二个月，客户反馈某个型号的库存和实物对不上，账面显示剩120箱，仓库实际只有95箱，差了25箱。排查过程是这样的：

第一步，查库存流水表，把该商品最近一个月的出入库流水全部导出来，看数量累加是否等于当前库存。结果发现流水对得上，说明问题不在出库环节。

第二步，查是否有直接改库存表的操作。果然，日志里有一条记录显示，某天凌晨有人通过管理后台的"库存修正"功能把该商品的库存从95改成了100，时间点正好和一次盘点操作吻合。继续查盘点单，发现那张盘点单的审批状态是"已驳回"，但盘点时的库存更新逻辑在驳回时没有做回滚，导致库存被改动了。

这个bug的根源在于：盘点单审批时调用了库存更新方法，但驳回时只更新了盘点单状态，没有恢复库存。解决方法是：驳回盘点单时，反向执行一次库存调整，把被改动过的库存恢复回去。同时给"库存修正"这个高危操作增加了权限限制和双人复核机制，只有超管才能操作，并且每次修正都会记录操作人和修正理由。

这类问题再次证明了我反复强调的那句话：所有库存变动必须走统一入口，所有入口必须留日志，否则出了问题只能大海捞针。

5.3 权限越权的隐蔽漏洞

还有一次安全测试时发现一个越权漏洞：仓管员登录后，虽然界面看不到采购管理菜单，但如果他手动在浏览器地址栏输入/purchase/order/detail/5，竟然能直接看到采购单详情。这个单子里有采购价，属于成本信息，仓管员不应该看到。

问题出在哪里？权限中间件只校验了菜单级别的权限，但具体到"能否查看某一条具体单据"，没有做二次校验。我的修复方案是：在控制器方法里增加数据级权限判断，比如查看采购单详情时，先检查当前用户角色是否有采购单查看权限，如果没有，直接返回403。这个校验不能只在中间件层做一次，因为中间件拿到的是路由规则和控制器方法名，很难处理"同一控制器方法在不同角色下有不同的数据可见范围"这种复杂情况。

修复后我总结了一条经验：权限控制永远要在两个层面做，一是路由级别（能否访问这个功能），二是数据级别（能看哪些数据、能操作哪些数据）。很多系统的权限漏洞出在只做了第一层，没做第二层。

6. 系统扩展方向与二次开发建议

6.1 多仓库与批次管理的演进

现在的系统是单次入库后库存混在一起，出库时没有指定批次。这对建材贸易行业不太够用，因为不同批次的采购价可能不同，成本核算需要按批次算，先进先出（FIFO）的成本结转也是财务上的刚需。

如果要上批次管理，数据模型上需要增加批次表（batch）：id、product_id、warehouse_id、batch_no、quantity、purchase_price、inbound_date。库存流水要引用batch_id，库存表本身还是要保持实时汇总，但底层数据支持按批次追溯。出库时按先进先出规则自动扣减批次库存。这个改造工程量不小，但一旦业务规模上来，就是必须做的。

6.2 对接移动端与扫码枪

客户用PC端系统用熟悉了，接下来一定会提移动端的需求。仓库盘点的时候，拿手机扫码或拿扫码枪扫商品条码，比在电脑上一个一个输入商品编码高效得多。

我的建议是不要急着做原生App，先用H5页面适配移动浏览器，配合微信企业号或钉钉工作台，开发成本低，上线快。扫码枪的话，本质上就是个键盘输入设备，扫出来就是商品条码加回车，前端监听回车事件触发查询即可。系统里要预留product_barcode字段，现在很多商品的条码就是69开头的13位EAN条码，不用额外打印标签。

6.3 数据备份与容灾预案

最后一条建议，也是我认为最重要的一条：进销存系统的数据是企业的生命线，一定一定要做好备份。我们用的是阿里云RDS MySQL，开启了自动备份，但我还额外做了一个每日凌晨的全量备份到OSS，保留最近30天。另外每周末做一次备份恢复演练，确认备份文件是可以正常恢复的——不要等到服务器挂了才发现备份文件是坏的，那就真的太晚了。

实际操作中，我还会用ThinkPHP的定时任务功能（crontab调用php think schedule:run）每天晚上做一次库存对账：把库存表的数量跟库存流水的累计变动做比对，如果对不上就自动发邮件报警。这套自动巡检机制上线之后，之前担心的"数据悄悄出错没人发现"的问题基本杜绝了。

我个人在实际操作中的体会是，进销存这种业务系统，技术难度真的不算高，难的是把业务流程理解透、把数据的一致性规则定清楚、把所有操作都留下痕迹。只要这三件事做扎实了，系统就成功了一大半。做这个项目最让我有成就感的一刻，是客户老板跟我说："上个月月底不用让仓库加班盘点了，电脑里的数和实物终于对得上了。"对于一套内部管理系统来说，这句话就是最好的验收报告。