每年资产盘点季高校资产管理员就要开始一场漫长的猫鼠游戏。打印出来的Excel表厚厚一摞扫码枪扫出来的条码和台账对不上问谁都说“东西在”但到现场就是找不到。我做这套基于Django的高校固定资产管理系统核心目标只有一个让账实相符成为一件默认会发生的事。系统覆盖了资产入库、领用、调拨、维修、盘点、报废的全流程也支持权限分级和台账导出。如果你正在为高校或类似的中大型机构规划资产管理系统或者想用Django把一个典型的业务系统从零落地上线这篇文章都能给你一条可以直接参考的路径和一堆真实踩坑记录。1. 高校资产台账的现状Excel、手工与“账实不符”的恶性循环1.1 先搞清楚参与的人和他们手里的资产做系统之前我习惯先列角色和对象清单。高校固定资产管理系统和普通企业的资产系统看着像但角色更复杂。高校里涉及资产的人大致有四类归口管理部门的资产管理岗负责全校资产的建账、处置审核和年度盘点组织各二级单位的资产员负责本部门的领用、报修、报废申请普通教职工是资产的实际使用人但往往只在领用时出现过一次校领导和财务部门他们不看明细只看总账、折旧和闲置情况。再往下拆是资产对象。房屋和构筑物属于特殊资产一般不进入日常的领用流程通用设备包括电脑、打印机、空调专用设备可能涉及实验仪器、实训设备还有家具装具、图书文物、无形资产。不同资产的买入方式、折旧年限、处置流程都不一样。比如实验仪器可能需要单独管理维护记录而家具和图书更新快、单价低管理颗粒度可以粗一些。如果一上来就按“统一资产表”建模后期肯定要返工。我的建议是先把资产类型和各自的管理规则列成一张矩阵再抽象公共字段而不是让数据库一开始就背上几十个专用字段。1.2 Excel为什么撑不住这些需求很多高校不是没有资产台账恰恰相反台账齐全到让人头皮发麻。问题在于维护方式。一份全校资产总表通常有上万行每个人手里都有一份“最新修改版”部门资产员更新了自己那一份汇总到学校时又覆盖了一部分数据。资产编号靠手工规则编制年份、部门代码、流水号一旦错位重号断号很难发现。盘点时的问题是台账更新和实物核对完全脱节。管理员拿着打印出来的Excel去各楼层扫码回来后在电子表格里手动标记“已盘到”“盘亏”“待追溯”。这个过程中任何一个字段被复制粘贴错了都不会有人察觉。账实相符靠的是人肉责任心和运气而不是机制。我接手这个项目前见过一个比较典型的案例某个部门搬家后资产员的Excel表里“使用部门”列没更新但“存放地点”已经改了。年度盘点时按部门筛选这批资产全部落在“旧部门”名下形成了大批盘亏项实际上资产就在新楼里。系统中的修改没有留痕没有审批也没有人知道是什么时候变的。1.3 系统要解决的四个核心问题这套Django系统从业务上要解决四个问题账实相符资产从入库开始就有唯一编号后续每一次状态变化都有记录盘点结果可以反向校正台账。过程留痕领用、调拨、维修、报废都走线上申请和审批每一步都要知道“谁在什么时候做了什么”。权责分明资产管理岗、部门资产员、普通教职工的权限不同。教职工只能看到自己名下的资产部门资产员只能操作本部门数据。决策支撑系统能输出部门资产分布、闲置资产、超期未盘点资产等统计数据而不是让领导继续看Excel透视图。业务边界同样重要。我当时和用户明确说明系统不做财务系统深度对接不做自动折旧入账因为高校折旧规则受财务制度约束需要由财务部门提供参数化规则后系统只负责按规则计算展示不替代财务系统。边界划清楚开发范围才能控制住。2. 技术与架构选型为什么是Django PostgreSQL2.1 Django在这个场景里赢在哪里选Django不是因为它最潮而是因为这类高校业务系统的几个硬指标Django正好都能满足。第一是ORM。高校资产系统的数据模型关系非常密集资产表要关联类别、部门、使用人、供应商还要跟审批、维修、盘点发生关系。如果用SQL手工堆后期维护成本很高。Django的ORM在模型变更、迁移管理上都比较省心配合makemigrations和migrate团队里新来的开发也能很快把库表更新起来。第二是自带Admin后台。开发早期我还没有做完整的运营管理界面时直接用Django Admin就能让资产管理岗先录入测试数据、调整基础字段。它相当于给业务方提供了一个可配置的后台原型帮我们省了一轮又一轮原型确认的时间。第三是用户认证和权限模型。高校系统必须区分管理员、资产员、普通教职工的权限。Django自带的Group和Permission模型已经能覆盖多数场景自定义权限也只需要扩展Meta.permissions。第四是安全能力。CSRF保护、XSS转义、SQL注入防护都是框架内置策略至少在合规层面给学校信息中心省了很多解释成本。2.2 为什么数据库选了PostgreSQL而不是继续用MySQL项目数据库最终选了PostgreSQL。主要原因是资产系统里除了结构化表格还有很多带可变属性的数据资产附件、审批详情、扫码盘点的临时快照、导入原始行等。PostgreSQL的JSONField天然适合存这类半结构化数据不用频繁改表。另一个原因是资产盘点需要处理并发写入。多个盘点小组同时提交盘点结果对同一批资产做状态更新PostgreSQL的行锁机制和select_for_update配合得很顺手。MySQL的InnoDB也能做但PostgreSQL在数据约束、索引方面给开发者的反馈更直观。如果学校已经有成熟的MySQL运维体系继续用MySQL也没问题但锁和隔离级别的测试一定要做足。实际开发中我用Django内置的django.contrib.postgres提供的数据库函数排查重复资产编号时写起来很快。后面踩坑部分会专门讲一个和驱动版本有关的例子这个选型直接影响了那个坑的定性。2.3 项目目录结构多应用拆分而不是一个大而全的app很多Django新手喜欢把所有模型写进一个models.py把所有视图塞进一个views.py。这个系统上线下线后还要长期维护我选择了按业务域拆分成多个应用asset_proj/ ├── config/ │ ├── settings/ │ ├── urls.py │ └── wsgi.py ├── apps/ │ ├── asset/ │ │ ├── models.py │ │ ├── services.py │ │ ├── views/ │ │ └── migrations/ │ ├── org/ │ │ ├── models.py # 部门、人员 │ │ └── services.py │ ├── approval/ │ │ ├── models.py # 审批单、审批记录 │ │ └── services.py │ └── report/ │ └── services.py # 统计报表 ├── utils/ │ ├── excel.py │ ├── asset_code.py │ └── qrcode_helper.py ├── templates/ ├── static/ └── requirements/每个应用只负责自己的业务闭环。资产应用不直接操作审批表而是调用approval.services.create_approval()。这样后面调整审批逻辑时不需要动资产模块的代码。导入导出这种通用逻辑放到utils里避免多个应用重复实现。3. 数据模型是系统的地基资产主表、部门树与审批模型的建模全过程3.1 资产主表字段宁缺毋滥但关键字段一个都不能少资产主表是整个系统的核心建模时经常陷入一个误区想把所有资产属性都塞进去。实验仪器要放规格型号家具要放材质尺寸软著要放登记证书编号。如果全做字段表会失控。我的处理方式是抽出公共字段特殊属性放到关联的AssetExtra表里用JSON存储。核心表模型大致是这个样子class AssetStatus(models.TextChoices): IN_STOCK IN_STOCK, 在库 IN_USE IN_USE, 使用中 REPAIRING REPAIRING, 维修中 SCRAPPED SCRAPPED, 已报废 class Asset(models.Model): asset_code models.CharField(资产编号, max_length64, uniqueTrue) name models.CharField(资产名称, max_length255) category models.ForeignKey( asset.Category, on_deletemodels.PROTECT, verbose_name资产类别 ) department models.ForeignKey( org.Department, on_deletemodels.PROTECT, verbose_name使用部门 ) keeper models.ForeignKey( settings.AUTH_USER_MODEL, nullTrue, blankTrue, on_deletemodels.SET_NULL, verbose_name使用人, ) status models.CharField( 状态, max_length20, choicesAssetStatus.choices, defaultAssetStatus.IN_STOCK, ) original_value models.DecimalField( 原值, max_digits12, decimal_places2 ) net_value models.DecimalField( 净值, max_digits12, decimal_places2 ) buy_date models.DateField(购置日期) location models.CharField(存放地点, max_length255, blankTrue) source models.CharField( 来源, max_length20, choicesSourceType.choices, defaultSourceType.PURCHASE, ) extra models.JSONField(扩展属性, defaultdict, blankTrue) created_at models.DateTimeField(建档时间, auto_now_addTrue) updated_at models.DateTimeField(更新时间, auto_nowTrue)几个设计决策值得说明一下asset_code必须是全局唯一索引。高校资产编号跨部门不能重复否则二维码标签、盘点扫码都会出问题。original_value和net_value用DecimalField绝对不用FloatField。资产金额可能到几十万浮点数误差会导致对账差出几块钱这种错误最不好解释。extra字段存特殊属性。比如实验仪器的“出厂序列号”“功率”家具的“材质”软著的“证书编号”。查询需要精确匹配时配合JSONField的索引和containment操作符使用。keeper允许为空。很多资产是部门公共设备没有固定使用人但必须归属到一个部门。3.2 部门树用parent自关联加缓存不上嵌套集合模型高校部门层级不深一般就是“学校-学院-系/中心-实验室”这种三到四层。网上很多文章推荐用django-mptt做树形结构。我评估后没有用原因有两个一是mptt对写操作有额外维护成本每次部门调整都要增量更新左右值出错后整棵树的查询就废了。二是高校部门变动频繁合并、更名每年都有递归自关联配合应用层缓存就足够。部门模型非常简单class Department(models.Model): parent models.ForeignKey( self, nullTrue, blankTrue, on_deletemodels.CASCADE, related_namechildren, ) name models.CharField(部门名称, max_length255) code models.CharField(部门代码, max_length32, uniqueTrue)查询某个部门及其下级部门的资产时我写了一个工具函数先把子树节点ID一次性取出来放到缓存里再拼到Django ORM的filter(department_id__in...)里。部门表数据量小读取完全够用复杂度却比mptt低得多。3.3 用一个审批模型承载所有业务单而不是做三套流程表领用、调拨、维修、报废看起来是四种业务但审批链路高度相似申请人提交部门资产员初审归口管理岗终审仓库或资产员执行。如果用四套流程表光是“查询我发起的待办”“查询待我审批的任务”就要写四遍。我最终用一个Approval模型承载所有业务单配合biz_type和biz_id反查具体业务对象class Approval(models.Model): biz_type models.CharField( 业务类型, max_length20, choicesBizType.choices, ) biz_id models.PositiveIntegerField(业务单ID) title models.CharField(审批标题, max_length255) submitter models.ForeignKey( settings.AUTH_USER_MODEL, on_deletemodels.PROTECT, related_name, ) status models.CharField( 审批状态, max_length20, choicesApprovalStatus.choices, defaultApprovalStatus.PENDING, ) current_node models.CharField(当前审批节点, max_length50) detail models.JSONField(审批上下文, defaultdict) created_at models.DateTimeField(auto_now_addTrue) class ApprovalRecord(models.Model): approval models.ForeignKey(Approval, on_deletemodels.CASCADE) user models.ForeignKey(settings.AUTH_USER_MODEL, on_deletemodels.PROTECT) action models.CharField( 动作, max_length20, choicesActionType.choices, ) comment models.TextField(审批意见, blankTrue) created_at models.DateTimeField(操作时间, auto_now_addTrue)Approval.detail里保存业务快照。比如报废审批提交时就把“报废原因、资产原值、净值、照片附件路径”都写进JSON。这样即使资产后续发生调拨或维修审批页展示的数据仍然是提交时的现场记录不会跟着漂变。审批记录只负责存每一步操作不重复存业务数据。3.4 用Signal记录资产履历避免业务逻辑散落各处资产状态变更要写履历表这是需求里明确写了“过程留痕”之后最先要落地的部分。如果每个视图里都手动写一段AssetLog.objects.create(...)后面加一个提醒功能很容易漏掉某个入口。我用Django Signal统一处理from django.db.models.signals import pre_save from django.dispatch import receiver receiver(pre_save, senderAsset) def asset_pre_save(sender, instance, **kwargs): if not instance.pk: return try: old Asset.objects.get(pkinstance.pk) except Asset.DoesNotExist: return changes [] for field in [status, department, keeper, location]: new_value getattr(instance, field) old_value getattr(old, field) if new_value ! old_value: changes.append({ field: field, old: str(old_value) if old_value is not None else None, new: str(new_value) if new_value is not None else None, }) if changes: AssetLog.objects.create( assetinstance, changeschanges, )这个方案虽然牺牲了一点性能但逻辑集中排查“资产状态是谁改的”特别方便。资产数量如果达到几十万批量导入历史数据时我会临时断开这个Signal导入结束后再重建日志。4. 核心功能模块的Django实现细节批量导入、领用、盘点、报废4.1 Excel批量导入第一步是清洗不是insert历史数据都在Excel里系统上线必然要做批量导入。但资产管理员手里的Excel长期人工维护格式问题非常多资产编号带空格、金额列被格式化成文本、日期列有的显示成2019/1/1有的显示成2019-01-01、同一个部门有两种写法。我当时写了一个导入服务第一遍先做格式清洗第二遍才入库。用openpyxl读取Excel逐行校验收集错误后一次性返回给前端from openpyxl import load_workbook from django.db import transaction def import_assets_from_excel(file): workbook load_workbook(file) sheet workbook.active errors [] success_count 0 for row_idx, row in enumerate( sheet.iter_rows(min_row2, values_onlyTrue), start2 ): asset_code str(row[0] or ).strip() name str(row[1] or ).strip() category_name str(row[2] or ).strip() ... if not asset_code: errors.append(f第{row_idx}行资产编号为空) continue if Asset.objects.filter(asset_codeasset_code).exists(): errors.append(f第{row_idx}行资产编号重复 {asset_code}) continue try: with transaction.atomic(): Asset.objects.create(...) success_count 1 except Exception as exc: errors.append(f第{row_idx}行{exc}) return {success: success_count, errors: errors}导入页面要支持下载模板模板字段和系统模型一一对应。上传后先展示错误列表而不是直接提示“导入完成”。这个体验细节很重要资产管理员需要知道到底哪些行没有进来以及为什么。实战中还要处理几个隐形问题Excel里的数字科学计数法资产编号如果是18位以上Excel默认会显示成科学计数法身份证长度类似的问题会让编号精度丢失。所以我给导入模板加了说明要求资产编号列必须设置为文本格式。服务端读取后统一做str(...).strip()再判断是否满足编码正则。4.2 领用与调拨事务保护加状态机校验领用和调拨的共同点是资产状态变化。领用是把在库资产变成使用中调拨是把使用部门或使用人变更。这两类操作如果不加控制就会出现“两个人同时申请领用同一台打印机”的尴尬。状态机约束放在模型层的services.py里而不是只靠视图里几行iffrom django.db import transaction from django.db.models import F def apply_for_asset(asset, applicant, target_department, target_keeper): with transaction.atomic(): locked_asset Asset.objects.select_for_update().get(pkasset.pk) if locked_asset.status ! AssetStatus.IN_STOCK: raise ValueError(f资产当前状态为{locked_asset.status}不可领用) locked_asset.status AssetStatus.IN_USE locked_asset.department target_department locked_asset.keeper target_keeper locked_asset.save() AssetAssignment.objects.create( assetasset, from_departmentasset.department, to_departmenttarget_department, operatorapplicant, )select_for_update()会把该行锁住直到事务提交或回滚。两个并发请求同时进来后一个会等待前一个释放锁再重新读取状态此时看到的已经是“使用中”校验就会失败。这个机制比单纯依赖前端按钮禁用可靠得多。调拨和领用的审批通过后要执行的就是这段服务函数。审批流和实际操作要分开审批是流程执行是服务。流程走完但执行失败时审批记录里要能查到失败原因系统要能支持作废重提。4.3 盘点任务、扫码与差异处理盘点是资产系统里最容易写复杂的功能。我的方案分三层InventoryTask一次盘点任务包含盘点范围、负责人、开始时间、截止时间。InventoryItem任务下每个具体资产的一条盘点记录保存扫码时间、盘点结果。InventoryIssue差异处理单记录盘盈、盘亏、待追溯以及后续的修正动作。盘点任务生成时可以从资产台账批量生成InventoryItem状态为“待盘”。盘点员用手机扫码后系统按资产编号查到这个盘点项进入确认界面。资产实际编号和台账一致勾选“已盘到”提交不一致则进入差异流程。差异处理是整个盘点的核心。实际做法是实物有但台账没有记为盘盈走资产补录审核台账有但实物没有记为盘亏进入调查确认流程实物编号和台账不一致记为待追溯需要人工核对。这些差异项不能直接修改资产表必须由资产管理岗审核后通过“盘点结果确认”按钮统一更新台账。这样一个盘点周期结束后系统能输出差异报告给管理层看哪些部门盘亏比例高哪些资产长期处于失管状态。手机上扫码我优先选了浏览器方案用getUserMedia调用摄像头识别条码后自动填充输入框并触发确认。没有做成原生App因为高校很难统一要求教职工安装App浏览器方案部署成本和培训成本都低。4.4 维修与报废业务闭环比页面复杂维修工单不是简单记一条“坏了找人修”就行。从资产台账角度看维修意味着资产状态要变成“维修中”期间不能再被调拨或处置。维修完成后状态回到可用的在库或使用中同时把维修费用、维修厂商、故障原因写入记录。报废处置要更谨慎。报废申请通过后资产状态变为“已报废”但资产本身还应该留在系统中不能直接删除。很多高校资产在报废后还要走实物处置流程包括拆解、回收、备案。所以我在资产表里保留SCRAPPED状态而不是删记录报废单里关联处置时间、处置方式、接收单位等信息。维修和报废都涉及图片附件我统一把附件目录按media/asset/{asset_code}/{yyyy}/{mm}/组织。上传时校验文件名改名为时间戳加扩展名避免中文文件名在部分浏览器下载时乱码。4.5 二维码标签生成与打印中的细节资产实物标签怎么打直接决定盘点工作量。我选了二维码加资产编号文本双排版中间一个二维码下面一行资产编号。打印时用热敏标签纸尺寸40mm×20mm打印精度203dpi。二维码内容不需要加密直接存资产编号。扫描后系统后台查编号显示详情没有网络连接时也能通过识别出的编号人工比对。这个方案比存URL更稳因为系统域名可能调整但资产编号不会变。生成用qrcode库关键是要保证二维码文本的编码正确import qrcode from qrcode.constants import ERROR_CORRECT_M def generate_asset_qrcode(asset_code): qr qrcode.QRCode( version2, error_correctionERROR_CORRECT_M, box_size4, border1, ) qr.add_data(asset_code) qr.make(fitTrue) img qr.make_image(fill_colorblack, back_colorwhite) return img标签打印时要注意缩放。二维码图像直接用图片格式贴到打印模板里不要从屏幕上截图再用容易失真。系统里做批量打印时按资产编号逐个生成图片然后拼成一个A4 PDF或直接发到标签打印机。我前几个版本直接调浏览器打印打印尺寸总差几毫米后来改成服务器生成PDF后下发问题才稳定解决。5. 开发中的五个真实踩坑从迁移失败到并发编号冲突5.1 SCRAM认证报错Django、psycopg2与PostgreSQL版本之间的暗坑系统第一次在测试环境跑数据迁移时报错信息很直接django.db.utils.OperationalError: SCRAM authentication is not supported当时第一反应是密码问题。检查settings.py里的数据库用户名密码、HBA配置都没错。查日志发现底层报到了psycopg2才意识到是Python驱动版本太老不支持PostgreSQL服务端的SCRAM-SHA-256认证。排查链路是这样的先看Django端的数据库配置确认URL模式没问题。看PostgreSQL日志里这条连接认证方式发现服务端要求SCRAM而驱动只支持旧版的MD5。用pip show psycopg2-binary确认版本确实是旧版本。升级到新版后迁移通过。这类问题很难从Django层面发现因为Django ORM只会把底层异常原样抛出来。遇到数据库报错时不要只盯着业务代码先确认整条链路里各组件版本是否匹配。5.2 IntegerField存金额一分钱引发的迁移第一版资产表里金额字段我图省事用了IntegerField单位是“元”。后续导入历史数据时Excel里的金额是12345.67元代码里int(12345.67)直接报错有的数据带角分直接丢精度。更麻烦的是已经录入的部分数据因为取整已经算错了。排查过程不复杂但教训很深金额字段从建模第一天就该用DecimalField不要为了省事用整数或浮点数。当时改正的办法是写了一个数据迁移脚本把旧的整数字段备份成历史列再新增DecimalField按原值重新解析导入。5.3 CSV编码乱码盘点批次导入第一关资产管理员喜欢用CSV从别的系统导出资产数据再导入到新系统。第一次测试时中文资产名称全部变成了乱码比如“办公椅”变成“鍔炲叕妞呫”。我拿到文件先查编码用chardet检测出来是GB18030而Django视图按UTF-8去读自然全乱。处理办法是在导入接口里做一个编码检测兜底import chardet def read_csv_with_encoding(file): raw file.read() detected chardet.detect(raw) encoding detected.get(encoding, utf-8) if encoding.lower().replace(-, ) in (gb2312, gbk): encoding gb18030 return raw.decode(encoding, errorsreplace)这里有个细节GB2312和GBK都尽量统一转成GB18030读取因为后者是前两者的超集解析兼容性更好。导入模板要强制注明编码方式同时服务端仍然要做自动检测两种手段一起上才能挡住历史数据这个最大的乱源。5.4 LoginRequiredMiddleware把所有页面都变成了登录页为了快速控制权限我写了一个中间件对所有请求做登录校验。上线自测时发现整个系统进了死循环访问/admin/被重定向到登录页访问登录页本身也被重定向到登录页最后连静态文件都被拦了。排查思路先看浏览器开发者工具里的网络请求发现连续302位置指向登录页。停掉中间件系统恢复确认问题出在中间件。检查中间件代码发现没有放行/accounts/login/、/static/和/admin/的白名单。修正后把白名单配置放进settings.py统一维护。这件事让我后来对“全局中间件”非常警惕。权限控制如果只需要作用于一部分视图优先用Django的LoginRequiredMixin或装饰器而不是写一个影响所有路由的中间件。全局中间件看着省事却很容易把登录页、静态文件、甚至回调URL一起卷进去。5.5 get_or_create处理并发资产编号差点造成重复资产资产编号生成规则是“部门代码年份四位流水号”例如CST-2024-0123。第一版生成流水号的逻辑是查当前最大值加一latest Asset.objects.filter( departmentdept, buy_date__yearyear ).order_by(-asset_code).first() seq int(latest.asset_code.split(-)[-1]) 1 new_code f{dept.code}-{year}-{seq:04d}两个管理员同时操作时可能查到的最大值一样生成相同的编号。我想当然地用get_or_create兜底asset, created Asset.objects.get_or_create(asset_codenew_code, defaults{...})问题在于get_or_create在“已经存在相同编号”时会返回旧对象但业务上这是两件资产只是编码撞了系统会把第二件资产申请直接夺回到第一件资产上造成误登记。正确处理分两步数据库层面保证asset_code唯一索引这是必须的底线约束。应用层捕获IntegrityError后重试或者用一个单独的表预分配编号片段避免每次都去查最大值。我当时用了一个简单但不那么优雅的方案在唯一约束触发冲突时捕获异常并重新生成编号重试重试次数上限5次。这个方案虽然没有预分配那么美观但足够解决并发场景而且代码容易理解。核心教训是get_or_create适合主键明确、冲突即同一条数据的场景不适合承载业务上需要新生成逻辑的记录。6. 部署上线后的运维与优化备份、nginx与标签打印的现场经验6.1 部署当天最容易翻车的几个环节部署到学校服务器时我提前列了一张检查清单逐项确认。Gunicorn作为一个简单的WSGI服务器来跑Django应用gunicorn -w 3 -b 127.0.0.1:8000 config.wsgi:application进程数量按CPU核数取两倍左右。如果服务器只有2核起4个worker同时配合超时配置避免请求卡死整个进程。前端加nginx做反向代理server { listen 80; server_name asset.local; client_max_body_size 20M; location /static/ { alias /srv/asset/static/; } location /media/ { alias /srv/asset/media/; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }client_max_body_size必须调大因为盘点时要上传照片默认1M根本不够用。/media/目录的权限也要确保Django进程能写入很多部署问题都产生在这里。静态文件收集同样容易漏python manage.py collectstatic --noinput如果漏了这一步nginx的/static/会全部404页面样式消失。上线前一定要在服务器本地用curl验证静态资源路径可访问而不是只在自己电脑上点了一遍。6.2 定时任务备份、折旧计算、超时提醒系统稳定运行后有几类定时任务必须保证可靠。数据备份我用的是系统cron加pg_dumppg_dump -Fc assetdb -f /backup/asset_$(date %Y%m%d).dump备份文件保留最近30天每天凌晨执行。这里额外提一个经验备份不能只做不恢复。每季度要拿一份备份到测试环境做一次恢复演练否则备份文件很可能在关键时候不可用。资产折旧计算我放在了Celery beat定时任务里每个月初运行。计算逻辑不直接写财务折旧结果只是生成一份“本月折旧试算表”给资产管理岗核对。真正入账操作由财务系统处理这里不越权。领用审批超过7天未处理系统要给发起人发提醒。这个任务也是每天执行一次扫描待审批记录超时的自动生成站内信通知。定时任务看起来简单但监控不能少任务执行失败的日志要能方便地查出来。6.3 现场盘点对手机和条码枪的适配盘点现场环境差异很大有的部门用手机扫码有的还用老式条码枪。条码枪本质上是模拟键盘输入扫码后直接把字符送到当前焦点输入框。这就要求扫码框必须能够自动聚焦并且扫完编码后要自动提交或跳到下一个框。我在盘点页面里做了这样一个处理资产编码输入框autofocus监听回车事件扫码枪扫完会自动带一个回车正好触发查询。手机上如果用摄像头扫码走浏览器API调用识别成功后自动填充并触发同一个提交函数。条码枪有一个经典坑输入法。如果页面里有中文输入法被激活扫进来的英文字母可能被输入法吞掉导致查询失败。所以盘点页尽量锁死键盘或提醒用户切换到英文输入法更省事的方式是扫码框用inputmodenone配合readonly避免移动设备弹出软键盘。6.4 上线后数据质量的持续维护系统上线不等于数据干净。历史数据导入第一批往往只能保证“数量对”不能保证“每一条都对”。我建议上线后第一个盘点周期里可以开一个“数据修正模式”资产员扫描实物时如果发现名称、型号、存放地点不符可以直接在盘点界面提交修正建议。修正建议不直接入库而是汇总给资产管理岗批量确认。这个机制比让人直接在系统里改资产主数据安全得多。它保留了“现场实际是什么”的证据也避免了资产员误操作覆盖正确数据。上线三个月后资产台账里那些批量导入产生的脏数据会逐步暴露编码规则不一致的老资产、历史部门合并后残留的旧部门归属、无使用人但有状态“使用中”的异常记录。我专门写了一个“数据质量报告”页面把这些异常规则列出来定期检查。最后分享两个系统改版时的真实体会如果让我重新做一次这套系统最想改动的地方是资产编号规则。编码方案上线后尽量不要改因为所有标签、历史单据、导入模板都依赖它。设计规则时最好提前预留扩展位而不是把“部门代码-年份-流水号”填得满满当当。另外别把资产管理员逼成数据录入员。系统能自动带出的字段就不要让人重复填写。资产名称、类别、品牌型号很多都能从采购订单或发票信息里带出来。能省一步就省一步这样资产员才愿意持续维护数据账实相符才不是一句空话。