前阵子有位做行政的朋友跟我吐槽，说公司两百多台办公设备，台账还停在Excel上，每次盘点要翻半天，新买的一批笔记本电脑发到部门手里，也没人记得登记具体责任人。到了年底对账，发现账实不符，怎么都查不出来龙去脉。聊到最后他说了一句让我印象很深的话：固定资产不是没管，是管的方式根本跟不上设备周转的速度。顺着这个话题，我开始帮他找开源的固定资产管理系统，最终敲定的是一套基于PHP的全开源方案，功能很齐全，专门面向IT办公固定资产管理，从入库、领用、归还、调拨到维修、报废、盘点都有完整闭环。这套系统部署简单、没有授权费用，还能按公司流程做二次开发。这篇文章就把我选型、部署、日常使用和二开的经验完整写出来，给同样被台账问题困扰的朋友一个参考。
1. 从Excel台账到自托管系统：为什么值得折腾
1.1 Excel台账的七个致命问题
先说说我朋友原来的做法。公司规定每台设备都要在Excel里登记，也安排了专人维护，可现实永远比规定复杂。几千条资产记录躺在同一个文件里，一旦遇到多人同时编辑，文件覆盖问题就会反复出现；设备被领走之后，台账上的状态能不能及时更新，完全取决于当事人记不记得去改。时间一长，Excel就变成了一份“记录了历史但描述不了现状”的静态表格。最常见的问题集中在这几类：
- 没有防覆盖机制，两个部门各存一份，月末汇总全靠手动合并。
- 资产状态依赖人工记忆，有人领了打印机、投影仪，台账还在“库存”。
- 盘点必须一台一台对资产编号，几百台设备下来，一天时间都未必够。
- 维修、借用、调拨这些过程没有历史记录，出了问题找不到责任人。
- 财务要折旧数据时，只能靠Excel公式自己算，还经常和资产台账对不上。
- 责任人调岗、离职后，名下设备没有自动转移，变成“无主资产”。
- 保修期、合同期到期没有提醒，过了保修才发现设备坏了。
这些事单独拎出来看都不大，但叠加起来就是年终对账的灾难。我朋友当时最大的感受是：大家都很努力地登记，却仍然说不清楚公司到底有多少台电脑。所以问题的根源不是人不够勤快，而是工具本身不具备“状态流”和“审计流”，Excel本质上只是一张静态表格，撑不起全流程管理。
1.2 自托管系统与SaaS工具的取舍
确定要上系统之后，摆在面前还有一道选择题：买现成的SaaS服务，还是自己部署一套开源源码？市面上很多云资管平台确实做得漂亮，注册就能用，扫码盘点、审批流都有。但实际聊下来，我发现朋友公司有几个很难妥协的顾虑。
首先是数据归属感。设备台账里包含采购金额、供应商、责任人、部门这类内部信息，放第三方平台上，虽然合同里写着保密，心理上还是觉得不踏实。其次是按资产数量收费，两百台设备一年的订阅费不算低，后续增加到五百台、一千台，费用翻倍。最麻烦的是自定义能力，云平台的字段、状态、审批逻辑都已经被产品方限定好了，公司想加一个“项目归属”字段，或者把“借用审批”塞进去，往往要等排期，甚至直接被告知无法支持。
自托管方案的逻辑正好相反。源码在手里，数据库结构看得见，改哪里都很自由；部署在内网服务器上，不依赖外网环境，办公网络断开时也能正常登记、查询；费用主要是自己一台服务器或虚拟机，几乎没有边际成本。对多数中小企业和有定制需求的公司来说，这套PHP资产管理系统源码的起点已经覆盖了80%以上的核心场景，剩下20%靠前端加个按钮、后端加张表就能解决，性价比明显更高。
2. 这套源码的功能地图：一条完整的资产流转链
2.1 资产台账：不只是一张表，而是一套主数据
系统登录之后，最先吸引我的是资产台账模块。它并不是简单把Excel里的列搬到网页上，而是把每台设备当成一条有状态、有归属、有轨迹的主数据来管理。每台资产可以记录的基本信息包括资产编号、资产名称、分类、品牌型号、序列号、供应商、采购日期、购买价格、存放地点、当前状态、责任人、部门、备注等。这些字段几乎覆盖了绝大多数IT设备的管理需求。
我比较看重的是“分类树”能力。公司里的资产不是扁平的一堆编号，而是有层级的，比如“IT设备”下面有“笔记本电脑”、“显示器”、“打印机”，而“办公家具”下面又分“工位椅”、“文件柜”。这套系统支持多级分类，选择分类的时候可以逐级筛选，后续报表也能按分类汇总。资产编号还支持自定义规则，比如按“类别-购入年份-流水号”生成，这样看到编号就能判断设备大概是什么时候进来的。
资产照片和电子凭证也可以挂到台账里，采购发票、验收单、保修卡这些附件不再需要单独存网盘，直接绑定到对应资产记录上。省去了一个很大的麻烦：以前查一台设备的发票要翻半年聊天记录，现在点开资产详情就能看到。
2.2 领用、归还、调拨与借用：流转过程有迹可循
台账只能解决“设备在哪”，真正难的是“设备怎么流转”。这套系统把日常流转相关的高频操作都做成独立功能：领用、归还、调拨、借用。以领用为例，管理员选中一台状态为“库存”的设备，登记领取人和使用部门后，系统会自动生成一条领用记录，并把设备状态改成“在用”，领取人账号里也能看到名下设备列表。
归还时，只需选择已领用的设备，系统自动解除绑定，状态重新回到“库存”或“待维修”。调拨则适合部门之间的资产转移，比如某员工从A部门调到B部门，名下笔记本电脑需要跟着走，管理员可以发起调拨单，同时保留调拨历史。借用功能是后来我们二开补上的，原系统对“临时用几天再还回来”的场景只有一个“借用中”状态，不够细，后面我会单独讲二次开发的实现。
整个流转过程的核心价值在于“记录不可赖账”。每一台设备什么时候被谁领走，什么时候归还，中间有没有维修记录，都跟着资产ID走。一旦出了纠纷，后台可以直接拉出这台设备的完整时间线，谁经手、谁审批、什么时候改的状态，一目了然。
2.3 维修、报废与折旧：给资产算好“真价值”
设备不可能永葆青春，固定资产管理必须覆盖“变坏”和“退出”的过程。这套源码把维修登记做成了独立模块，管理员可以给设备创建维修单，填写故障描述、维修费用、维修结果，维修期间设备状态自动切到“维修中”，修好后可以选择“返回使用”或“转入待报废”。这样一来，设备是否总在坏、哪类品牌故障率高，都能通过历史维修记录统计出来，为后续采购决策提供依据。
报废流程同样严谨。选择“报废”时必须填写处理方式，比如出售、回收、破坏性销毁，系统会把报废原因、时间、经办人记录下来。尤其对IT设备来说，硬盘数据销毁是个合规问题，报废记录里最好注明是否有数据清除操作，这套系统允许自定义备注字段，所以可以直接把“硬盘已格式化并验证”写进去。
折旧模块对我朋友那种要应付财务审计的公司特别有用。系统支持按年限平均法计算月折旧和残值，设定预计使用年限后，每月自动生成折旧金额，资产原值、累计折旧、账面净值都能在资产详情里看到。这个功能省去了财务手工做折旧分配表的麻烦，也减少了资产台账与财务账不符的尴尬。
2.4 盘点与标签打印：把线上台账带到线下
资产管理的闭环里，盘点是最累的一环。这套系统提供了“盘点计划”功能，管理员可以创建一次盘点任务，选好范围（比如某个部门或某个分类），系统会把范围内的资产列成盘点清单。盘点时可以直接在清单里勾选“已找到”和“未找到”，也可以给每台设备贴上二维码，后续配合扫码枪或手机摄像头逐台扫码，效率比手工抄编号高很多。
标签打印这块，系统内置了二维码标签模板。资产入库后可以直接生成一张A5或60mm×40mm的打印页面，用普通激光打印机就能打，也可以接兄弟、得实这类常见条码打印机。二维码里存的是资产编号或资产详情页地址，扫出来就能看到这台设备的所有状态信息。我们后来在标签上加了公司Logo和“设备编号”字样，改模板也比较方便。
我个人的建议是，如果你的资产数量超过两百台，盘点功能会成为用得最多、也最能体现系统价值的模块。因为扫码盘点的效率提升不是线性翻倍，而是从“几个人忙一整天”变成“一个人推着扫码车转半天”。
3. 源码结构与技术细节：读懂它才能顺利扩展
3.1 技术选型：为什么PHP依然是省心方案
选这套PHP资产管理系统源码，很大一部分原因是它的技术栈足够亲民。以我拿到的这份源码为例，后端采用PHP语言开发，要求PHP 7.4及以上版本，数据库使用MySQL 5.7或更高版本，Web服务器可以用Nginx也可以用Apache，整体部署要求非常低。一台2核4G的虚拟机跑个小公司两三百台设备绰绰有余，甚至复用公司内部已有的旧服务器也能流畅运行。
有人可能会问，现在新项目不是都在用Go、Python或者Node.js吗？老实说，技术新不代表运维方便。对大多数负责行政或IT支持的同事来说，PHP项目最大的优势是“看得懂的人多、修得起的人多”。出了问题随便找个外包开发都能上手，不像冷门技术栈那样挑人。而且PHP对MySQL的操作很原生，资产台账这种以增删改查和报表为主的项目，用PHP做非常匹配。
源码还使用了Composer管理依赖，这意味着所有第三方库的版本都能锁定。首次部署时执行“Composer install”就能把后端依赖拉全，不需要手动去网上下载各种包。前端样式基于Bootstrap这类成熟组件库，哪怕不熟悉前端框架的人，也能靠着现成的CSS类名把页面改得符合公司风格。
3.2 目录结构和MVC分层
第一次打开源码目录时，你会发现结构非常标准，核心入口集中在public目录，业务代码按控制器、模型、视图、路由四个维度拆开。我简单列一下典型结构：
- public：Web入口目录，部署时站点根目录直接指到这里，保障应用源码不外泄。
- app/Http/Controllers：控制器层，处理请求、调用模型、返回页面或JSON数据。
- app/Models：模型层，负责和数据库表打交道。
- resources/views：视图层，存放前端HTML模板。
- routes：路由注册文件，定义了各种URL地址对应到哪个控制器方法。
这样的分层带来的直接好处是：改页面不用碰数据库逻辑，加字段不用去前端模板里面乱翻。比如我想在资产列表页增加“项目编号”一列，先确认表里有没有字段，没有就加字段，然后在模型里把字段加到可填充列表，最后在视图模板的表格头和表格体里各加一层HTML代码，十几分钟就能搞定。
3.3 数据库表设计的几个关键点
资产管理系统的核心其实在数据库模型上。常见的表大致有这些：用户表、角色权限表、资产分类表、资产台账表、存放地点表、供应商表、领用记录表、维修记录表、盘点明细表等。资产台账表会通过外键关联分类、地点、供应商、责任人，形成一张完整的资产信息网。
值得一说的是“操作日志表”。这套系统几乎所有关键操作都会写日志，包括新增资产、修改状态、领用、归还、删除等。日志表记录了操作人、操作时间、操作类型、IP地址和操作前后的字段变化。这个表平时不起眼，但一旦出现“资产莫名其妙不见了”的情况，它就是排查的命脉。
另外资产状态字段通常不是写死在代码里的，而是存成一张状态字典表。这样做的好处是扩展状态时不需要改代码，直接在后台或者数据库里加一行“维修中”或“已外借”就行。很多刚刚接触这套源码的人会忽略这一点，直接在代码里写死了状态字符串，结果后面加状态时到处报错。我建议所有二次开发都遵循“字典优先”的原则，能进表配置的不要写死在代码里。
4. 部署实录：从下载源码到正式跑起来
4.1 环境准备：手把手搭一套LNMP
我实际部署用的是一台Ubuntu 20.04虚拟机，配置是2核4G。操作系统装好后，依次安装Nginx、MySQL和PHP，同时把PHP的扩展装上。这里特别提醒一句：PHP的pdo_mysql、mbstring、fileinfo、openssl、zip、gd这些扩展不能漏，缺一个都可能在上传图片或导出文件时报错。
以Ubuntu为例，安装好基础环境后，用Composer拉取项目依赖。命令大致如下：
# 更新系统源 sudo apt update # 安装PHP及扩展 sudo apt install php7.4-fpm php7.4-mysql php7.4-mbstring php7.4-xml php7.4-curl php7.4-zip php7.4-gd # 安装MySQL和Nginx sudo apt install mysql-server nginx # 安装Composer curl -sS https://getcomposer.org/installer | php sudo mv composer.phar /usr/local/bin/composer如果你用的是Windows服务器也完全可以跑，但生产环境我强烈建议放在Linux上，一方面是资源占用更低，另一方面是后面做计划任务（比如备份、折旧计算）方便。
4.2 部署五步：从源码包到系统可访问
第一步，把源码包上传到服务器目录，比如“/var/www/asset”，在项目根目录执行：
composer install --no-dev这一步会把项目依赖的第三方库全部就位。如果网速不理想，可以把vendor目录一起上传，省略这步。
第二步，创建数据库和账号。登录MySQL后，新建一个数据库，名字可以用“asset_db”，字符集选utf8mb4，再建一个专用账号并授权：
CREATE DATABASE asset_db DEFAULT CHARACTER SET utf8mb4; CREATE USER 'asset_user'@'localhost' IDENTIFIED BY '自定义密码'; GRANT ALL PRIVILEGES ON asset_db.* TO 'asset_user'@'localhost'; FLUSH PRIVILEGES;第三步，导入数据库表结构和初始数据。源码包里一般会有“asset.sql”或“database.sql”文件，执行：
mysql -uasset_user -p asset_db < asset.sql导入完成后，可以先用命令行看一眼有没有核心表，确认成功。
第四步，修改环境配置。大部分PHP项目会提供.env.example文件，我通常复制一份为.env，然后填数据库连接信息、应用URL、时区等关键项。重点检查APP_URL、DB_HOST、DB_PORT、DB_DATABASE、DB_USERNAME、DB_PASSWORD这几项。
第五步，配置Web服务。站点根目录指向项目的public目录，并设置伪静态规则。Nginx伪静态配置大概是：
server { listen 80; server_name asset.example.com; root /var/www/asset/public; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php7.4-fpm.sock; } }配置完成后，设置storage和uploads目录的写权限，然后重启Nginx和PHP-FPM。浏览器打开站点，如果能看到安装向导或者登录页面，说明部署已经成功了一大半。
4.3 初始化设置：别急着录资产
系统装好后，第一件事不是录资产，而是先把基础数据配好。通常需要完成这几步：
- 修改默认管理员密码，并建立一套强弱分离的角色账号。
- 配置公司名称、资产编号前缀、默认存放地点。
- 建立资产分类模块，把“IT设备”、“办公家具”、“通讯设备”等大类先建好。
- 配置供应商档案，方便后续采购记录关联。
- 如果系统支持邮件通知，填写SMTP信息；不支持的话，至少把导出报表功能跑通。
我朋友就吃过亏，他把所有设备都录进去之后才发现部门结构没建对，后来重新调整责任人和部门，数据改了两天。所以基础配置一定要先于资产录入，顺序不能反。
5. 真实使用半年，我总结的避坑清单
5.1 权限设计：把角色想清楚再分账号
很多管理员天生习惯用超级管理员账号办所有事，刚开始觉得方便，用久了就会后悔。因为一旦每个人都用最高权限登录，后台的操作日志无法区分“谁干的”，万一有人误删资产或者乱改状态，排查起来等于大海捞针。
我建议按照实际管理流程把角色至少分成四类：系统管理员，负责参数配置和账号管理；资产管理员，负责设备入库、领用、调拨、盘点；部门负责人，可以查询本部门资产和提交领用申请；普通员工，只能查看名下设备。这套PHP源码大多已经内置了角色和权限模块，二开时可以按路由或菜单来限制权限。权限设计看起来很琐碎，但它是后期管理秩序的基础。
5.2 标签打印：打印机兼容性问题比想象中多
标签打印这块，我踩过一个比较隐蔽的坑。系统生成的是HTML页面，打印控制权其实在浏览器手里。如果你用的是一台热敏标签打印机，不一定能像激光打印机那样直接“所见即所得”地打印，因为热敏打印机通常需要专用驱动甚至指令模式。
我的建议是：如果资产数量不大，直接用普通激光打印机配合A4不干胶标签纸，一张A4上排多枚标签，裁剪后贴到设备上，这是最简单稳定的方案。如果资产数量很大、每天都有新设备入库，那就要单独配一台支持Windows打印驱动的标签打印机，并确认源码里打印模板的纸张尺寸和驱动匹配。先打一张测试，量好标签之间的距离，再批量打印，否则很容易出现标签内容“跑偏”到下一页。
5.3 备份与恢复：定时任务不能省
系统跑起来后，很多人的误区是“服务器不坏就不用备份”。固定资产台账是企业的资产底账，一旦数据库损坏，恢复成本极高。我帮朋友部署这台服务器时，顺便写了一个每天凌晨备份数据库和上传目录的脚本，保留最近30天的备份文件：
#!/bin/bash BACKUP_DIR=/data/backup/asset DATE=$(date +%F) mysqldump -uasset_user -passet_pwd asset_db | gzip > "$BACKUP_DIR/asset_$DATE.sql.gz" tar -czf "$BACKUP_DIR/uploads_$DATE.tar.gz" -C /var/www/asset public/uploads find "$BACKUP_DIR" -type f -mtime +30 -delete配合crontab每天凌晨2点执行一次。这里有个细节要注意：mysqldump的密码不要直接写在命令行参数里，因为会在系统进程列表里暴露，建议把密码写进“~/.my.cnf”配置文件。备份文件最好再同步到另一台机器或对象存储，避免服务器磁盘故障时备份也没了。
5.4 常见故障：404、图片不显示、登录失效
用久了难免会遇到几个重复出现的问题。我整理三个最常见的：
第一个是部署后首页打开正常，但点击菜单跳转全是404。绝大多数情况是伪静态没有配置好，或者Apache下面的.htaccess规则没生效。检查一下Nginx配置里的“try_files”规则是否指向了public/index.php。
第二个是上传资产照片和附件后，前台图片裂了。先检查uploads目录权限，再检查PHP上传配置，php.ini里的“upload_max_filesize”和“post_max_size”要及时调大，否则超过2M的图片会静默失败。
第三个是后台登录过一会儿就失效，特别是在Chrome浏览器里。这个问题通常是PHP会话目录没有写权限，或者session保存时间太短。检查storage/framework/sessions目录是不是PHP用户可写，再把会话过期时间调长一点。不要一上来就怀疑源码有安全漏洞，多数时候是运行环境没有配好。
6. 二次开发实战：给原系统加上“资产借用审批流”
6.1 需求场景：临时借用也需要留痕
朋友公司经常有跨部门借用投影仪、摄像机和外接硬盘的情况。原来流程是微信上喊一声，然后到行政那边拿设备，用完还回来。问题在于：设备有没有被真正归还，只有行政自己记得；一旦连续借出两三台，就很容易混淆。所以需要在原系统里增加一个“借用审批”流程：员工发起借用申请，部门负责人审批，行政确认出库，到期后自动提醒归还。
这个需求在原源码里没有完全覆盖，“借用中”只是一个状态，没有审批环节。好在整套PHP源码的分层结构清晰，扩展起来不算难。
6.2 数据库设计与后端逻辑
先建一张“资产借用单”表，字段包括：
CREATE TABLE asset_borrow_orders ( id INT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL COMMENT '借用单号', asset_id INT NOT NULL COMMENT '资产ID', applicant_id INT NOT NULL COMMENT '申请人ID', approver_id INT NULL COMMENT '审批人ID', borrow_date DATE NOT NULL COMMENT '借用日期', expect_return_date DATE NOT NULL COMMENT '预计归还日期', actual_return_date DATE NULL COMMENT '实际归还日期', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待审批 1已批准 2已拒绝 3已归还 4已逾期', remark TEXT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );后端在资产控制器里新增两个接口：提交借用申请、审批借用单。借用申请提交时，先检查设备的状态是否为“库存”或“可用”状态，不是就返回错误提示；审批通过后，把设备状态改为“借用中”，并生成一条操作日志。归还时更新实际归还日期，同时把设备状态改回“可借”。
伪代码思路是这样的：
public function storeBorrow(Request $request) { $asset = Asset::find($request->asset_id); if ($asset->status != 'available') { return back()->withErrors('该设备当前不可借用'); } AssetBorrowOrder::create($request->all()); return redirect()->back()->with('success', '借用申请已提交'); } public function approveBorrow($id) { $order = AssetBorrowOrder::find($id); $order->status = 1; $order->approver_id = auth()->id(); $order->save(); $order->asset->status = 'borrowed'; $order->asset->save(); // 写入操作日志 }6.3 前端入口与权限控制
前端改造更简单。在资产详情页增加一个“申请借用”按钮，点击后弹出表单，选择预计归还日期和备注，提交就行。审批页面单独做一个列表，只显示状态为“待审批”的借用单。权限控制上，借用按钮对普通员工可见，审批列表只对部门负责人和资产管理员可见。
这里我踩过一个细节坑：资产状态字段在不同页面里的叫法不一致，有的地方是“可用/占用”，有的地方是“库存/在用”，导致前端判断状态时写错条件。所以二开时最好先统一定义一份状态映射，或者在数据库字典表里把状态名称统一。二开完成后，测试用例要覆盖“设备已被领用时再申请借用”、“申请后取消”、“归还日期超过今天仍没有归还”三种场景。
6.4 上线后的迭代：逾期提醒没有想象中复杂
上线运行后，朋友又提了一个新需求：借用到期没还，系统要提醒申请人和行政。这个功能我建议不要塞进页面循环里，而是写一个命令行脚本，每天凌晨跑一次，把“expected_return_date < 今天 且 status=1”的借用单查出来，发邮件通知，同时把状态更新为“已逾期”。脚本挂在crontab里，和数据库备份任务一起执行。
这样一套走下来，整个借用流程从“微信消息”变成了系统里的正式单据，任何设备借出借入都有据可查。行政同事不需要再靠记忆应付多人借用，月底还能统计出哪些设备被借用频率最高，为采购决策提供依据。
第二次开发做完之后我最大的感受是，PHP资产管理系统源码的“全开源”价值并不在于免费，而在于你能按自己公司的流程把它改到顺手。数据库表结构、控制器逻辑、页面模板全部在手，只要思路清晰，改一个审批流差不多就是“加表、加接口、加页面”三步走，不需要重新造轮子。
最后再分享一个小建议：不管你的公司现在有多少台设备，尽早把台账系统落地，永远比等到账实差距大到不可收拾时再补救要轻松。如果暂时不具备部署条件，也可以先在本机搭一套跑通体验一下，带一台真实设备走完入库、打印标签、领用、归还、盘点的完整流程，十分钟就能体会到Excel台账和系统化管理之间的差别。
