自助装机报价系统：硬件兼容校验与价格快照全链路实践

简介《韩枫自助装机和硬件报价系统》是一套面向电脑装机店、硬件商家及ASP学习者的整站源码侧重解决配件报价展示、自助选配与订单留言等日常业务需求。前台提供配置查询、按CPU或主板型号自动搭配主机并计算总价、生成机器ID便于回查今日报价支持价格波动展示留言板兼顾产品订购信息后台按超级管理员、高级管理员与数据录入员分级授权支持MD5密码、数据库在线备份恢复压缩及SQL批量处理并可维护新闻、产品与品牌报价。压缩包为rar格式共142个文件以51个asp动态页面、16个inc包含文件为核心配有47个gif与19个jpg界面素材、1个mdb数据库及css、txt等辅助文件下载页显示包大小为0B。已有433人学习适合参考其前后台模块划分、权限控制和报价数据结构用于课程设计或小型硬件商城原型搭建。1. 自助装机报价系统把「客户自选配置 当场出价」做成一条能跑通的链路客户坐在店里指着一块主板问「换成这个多少钱」店员打开表格改三个格忘了同步散热器那一行报价单和实际配置对不上——这种事故在小装机店里并不稀罕。自助装机和硬件报价系统要解决的就是这条链客户在页面自选 CPU、主板、内存、显卡、机箱、电源系统按当前价格实时算总价顺手把插槽不匹配、内存代不对、显卡塞不进机箱、电源功率不够这些硬冲突挡在提交之前最后生成一张能打印、能存档、价格冻结在当天的配置单。这份源码包是典型的全栈 CRUD 业务前端选配、后端算价、后台维护配件与价格。它适合三类人——想找一个业务逻辑不空洞的练手项目的开发者、需要给门店做报价工具的小团队、拿它当课程设计骨架的学生。逻辑不难坑集中在价格口径和兼容性字段上。2. 硬件数据建模一张部件表怎么装下 CPU、主板和机箱的差异字段动手改这份源码之前先把表结构看明白否则后面加一条规则就要改一次库越改越乱。装机和报价这类业务的数据模型有个特点所有配件的「通用属性」高度一致品牌、型号、状态、价格但「差异属性」几乎没有交集——CPU 关心插槽、核心数、TDP主板关心板型、内存类型、M.2 数量机箱关心限长、限高、支持板型电源关心额定功率和供电接口。这两类属性混在一张表里结果就是几十个字段里一半永远是 NULL新人接手时根本判断不出哪一列对哪个分类有效。2.1 选型主表 规格 JSON 价格历史表的三层结构我一般会把配件数据拆成三层。第一层是分类表把 CPU、主板、内存、显卡、固态、电源、机箱、散热器这些做成数据行而不是硬编码枚举加一个新品类比如风扇、显示器只需要插一行不用改代码分支。第二层是配件主表只保留所有分类都有的通用字段差异字段全部塞进一个 JSON 列。第三层是价格历史表只追加不修改报价单永远能回溯到下单那一刻的价格。JSON 存规格的代价要说清楚它不能像普通列那样建索引做范围筛选所以「显卡长度」「电源功率」这两个高频筛选字段我会从 JSON 里冗余抽成主表的独立整数列。这叫「写的时候多一步查的时候省一大截」。冗余列和 JSON 的一致性靠导入脚本和应用层写入保证不能靠数据库约束——这是这套结构唯一需要人工守住的纪律。数据层存什么为什么单独拆出来category分类短码、展示名、排序新增品类不改表结构part品牌、型号、状态、冗余筛选列、spec JSON通用字段统一差异字段不污染表price_snapshot成本价、售价、生效时间报价单要冻结历史价格build / build_item单号、总价、明细单价快照配件下架、改名不影响历史单2.2 建表 SQL五张核心表和外键关系下面这段是核心 DDLSQLite 语法迁到 MySQL 只需要把INTEGER PRIMARY KEY换成BIGINT AUTO_INCREMENT把datetime(now,localtime)换成NOW()。-- 配件分类cpu / mainboard / ram / gpu / ssd / psu / case / cooler CREATE TABLE category ( id INTEGER PRIMARY KEY, code TEXT NOT NULL UNIQUE, -- 程序里用的短码如 mainboard name TEXT NOT NULL, -- 展示名如 主板 sort_no INTEGER NOT NULL DEFAULT 0 ); -- 配件主表只放所有分类都有的通用字段 CREATE TABLE part ( id INTEGER PRIMARY KEY, category_id INTEGER NOT NULL REFERENCES category(id), brand TEXT NOT NULL, model TEXT NOT NULL, spec TEXT NOT NULL DEFAULT {}, -- 差异字段全在 JSON 里 max_length_mm INTEGER, -- 显卡/散热器长度机箱分类下表示限长 power_w INTEGER, -- 电源额定功率其余分类表示估算功耗 status INTEGER NOT NULL DEFAULT 1, -- 1 在售 0 下架 created_at TEXT NOT NULL DEFAULT (datetime(now,localtime)) ); CREATE INDEX idx_part_cat_status ON part(category_id, status); -- 长度筛选走索引避免全表扫 JSON CREATE INDEX idx_part_len ON part(category_id, max_length_mm); -- 价格历史只追加不 UPDATE CREATE TABLE price_snapshot ( id INTEGER PRIMARY KEY, part_id INTEGER NOT NULL REFERENCES part(id), cost NUMERIC NOT NULL, -- 进货成本 price NUMERIC NOT NULL, -- 对外售价 effective_at TEXT NOT NULL, -- 生效时间支持提前录入未来价 created_at TEXT NOT NULL DEFAULT (datetime(now,localtime)) ); CREATE INDEX idx_price_part_time ON price_snapshot(part_id, effective_at DESC); -- 配置单主表与明细表 CREATE TABLE build ( id INTEGER PRIMARY KEY, sn TEXT NOT NULL UNIQUE, -- 单号如 B20240512001 total NUMERIC NOT NULL, -- 成交总价落库后不再随价格变动 service_fee NUMERIC NOT NULL DEFAULT 0, created_at TEXT NOT NULL DEFAULT (datetime(now,localtime)) ); CREATE TABLE build_item ( id INTEGER PRIMARY KEY, build_id INTEGER NOT NULL REFERENCES build(id), part_id INTEGER NOT NULL REFERENCES part(id), qty INTEGER NOT NULL DEFAULT 1, unit_price NUMERIC NOT NULL, -- 下单瞬间的价格冻结 part_name TEXT NOT NULL -- 冗余型号名配件改名或下架也不影响历史单 );price_snapshot上的(part_id, effective_at DESC)索引是整套系统的性能关键点每次报价都要对每个配件取「生效时间不晚于当前时间的最新一条」没有这个索引一张配置单 8 个配件就是 8 次全表扫描。build_item里冗余part_name看着不优雅但这是血泪经验——配件下架后被物理删除历史报价单里只剩一个 part_id客户来对账时你连型号都念不出来。2.3 spec JSON 的字段约定与单位统一JSON 好用但必须有约定否则同一个含义会写出三种键名。项目里我在docs/spec_schema.md固定了一套键导入脚本按分类做校验分类必填 spec 键单位/取值cpusocket、tdp_w、cores插槽字符串、瓦特、整数mainboardsocket、memory_type、form_factor、m2_slots如 AM5、DDR5、ATX、2rammemory_type、capacity_gb、sticksDDR4/DDR5、GB、条数gpulength_mm、tdp_w、power_connectors毫米、瓦特、8pin 数量psuwatt、efficiency、connectors瓦特、80PLUS 等级casemax_gpu_mm、max_cooler_mm、form_factors毫米、毫米、数组coolerheight_mm、socket_support、tdp_w毫米、数组、瓦特单位统一是最容易被忽略的一条。见过有人把机箱显卡限长录成0.35单位米校验时拿 320mm 去比结果所有显卡都判超长也见过功率录成650W带单位的字符串做加法时直接抛类型错误。约定是长度一律整数毫米功率一律整数瓦特纯数字入库单位只出现在展示层。写导入脚本时我一般会加一条断言非数字直接拒绝入库宁可导入失败也不要脏数据躺进库。2.4 批量导入从 CSV 到库的一条命令后台一个个手工录入不现实配件资料通常是供应商给的表格。下面这个脚本把 CSV 转成part记录差异列自动收进 JSON支持试运行。# tools/import_parts.py # 用法python tools/import_parts.py --file data/cpu.csv --category cpu # python tools/import_parts.py --file data/cpu.csv --category cpu --dry-run import argparse, csv, json, sqlite3, sys # CSV 里这几列落到主表列其余全部进 spec JSON COMMON {brand, model, max_length_mm, power_w} def parse_args(): p argparse.ArgumentParser() p.add_argument(--file, requiredTrue, helpCSV 路径) p.add_argument(--category, requiredTrue, help分类短码需已存在于 category 表) p.add_argument(--db, defaultdata/build.db) p.add_argument(--dry-run, actionstore_true, help只校验不写库) return p.parse_args() def to_int(v, field, line): if v in (, None): return None try: return int(v) except ValueError: sys.exit(f第 {line} 行 {field} 不是整数{v!r}请先统一单位) def main(): args parse_args() conn sqlite3.connect(args.db) row conn.execute(SELECT id FROM category WHERE code?, (args.category,)).fetchone() if not row: sys.exit(f未知分类 {args.category}请先在 category 表插入) cat_id row[0] # utf-8-sig 吃掉 Excel 导出带的 BOM否则第一列表头会变成 \ufeffbrand with open(args.file, encodingutf-8-sig, newline) as f: lines list(csv.DictReader(f)) ok skip 0 with conn: # 整个文件一个事务中途报错全部回滚不留半截数据 for i, r in enumerate(lines, start2): if not r.get(model): print(f第 {i} 行缺 model跳过); skip 1; continue spec {k: v for k, v in r.items() if k not in COMMON and v not in (, None)} conn.execute( INSERT INTO part(category_id, brand, model, spec, max_length_mm, power_w) VALUES(?,?,?,?,?,?), (cat_id, r[brand], r[model], json.dumps(spec, ensure_asciiFalse), to_int(r.get(max_length_mm), max_length_mm, i), to_int(r.get(power_w), power_w, i)), ) ok 1 if args.dry_run: conn.rollback() print(f成功 {ok} 条跳过 {skip} 条{试运行未写库 if args.dry_run else }) if __name__ __main__: main()参数上--dry-run是给自己留的后悔药先用它跑一遍看有没有单位写错、型号缺失确认干净了再去掉。encodingutf-8-sig这一行不是可选项国产办公软件导出的 CSV 默认带 BOM不加这个参数你会得到一个字段名叫\ufeffbrand的表然后r[brand]抛 KeyError排查半天以为是编码问题其实是表头问题。事务包住整个循环一条脏数据不该毁掉半张表也不该留下导了一半的中间状态。3. 兼容性校验9 条规则把「点不亮」的配置挡在提交之前这套系统真正的价值不在算钱而在拦截。算术用计算器也能做但「这条内存能不能插这块板」「这张显卡塞不塞得进这个机箱」是新手最容易翻车的地方也是门店被退货的主要原因。校验做得好客户在页面上自己就能发现配置有问题做得差等于把错误往后推到了装机台上。3.1 九条规则的判定字段与分级规则不是拍脑袋想的是从售后返修单里倒推出来的。我把它们按「不满足会怎样」分成三级error 直接禁止提交warn 允许继续但要客户确认info 只是建议。编号规则判定字段级别R1CPU 插槽 主板插槽cpu.socket / mb.socketerrorR2内存代 主板支持代ram.memory_type / mb.memory_typeerrorR3主板板型 ∈ 机箱支持列表mb.form_factor / case.form_factorserrorR4显卡长度 ≤ 机箱限长gpu.length_mm / case.max_gpu_mmerrorR5电源额定功率 ≥ 整机功耗 × 1.3psu.watt / Σ tdp_werrorR6散热器高度 ≤ 机箱限高cooler.height_mm / case.max_cooler_mmerrorR7M.2 硬盘数 ≤ 主板 M.2 槽位count(ssd) / mb.m2_slotserrorR8散热器支持对应插槽cooler.socket_supporterrorR9电源供电接口够显卡用psu.connectors / gpu.power_connectorswarnR5 的 1.3 系数是经验值不是物理定律。整机 TDP 加总只算了 CPU 和显卡的标称功耗主板、内存、硬盘、风扇、水冷泵都要吃电再加上瞬时功耗尖峰留 30% 余量在大多数配置上够用。如果客户配的是高功耗显卡我一般会把系数调到 1.4别在这上面省。3.2 规则函数统一返回结构别让每条规则各写各的规则最容易写崩的地方是返回格式五花八门——有的函数返回布尔有的返回字符串有的抛异常。统一成一个Issue结构前端才能稳定渲染。# app/compat/rules.py from dataclasses import dataclass dataclass class Issue: level: str # error / warn / info code: str # 稳定错误码前端据此把提示挂到具体配件行 message: str def _spec(sel, key): 取某个分类已选配件的 spec未选返回 None part sel.get(key) return part[spec] if part else None def rule_socket(sel): cpu, mb _spec(sel, cpu), _spec(sel, mainboard) if not cpu or not mb: return [] # 配件没选齐不做判断 a, b cpu.get(socket), mb.get(socket) if not a or not b: # 字段缺失时给 warn不能静默放行——这是最常见的漏判来源 return [Issue(warn, SPEC_MISSING, 插槽字段为空无法校验 CPU 与主板)] if a ! b: return [Issue(error, SOCKET_MISMATCH, fCPU 插槽 {a} 与主板 {b} 不匹配)] return [] def rule_psu_power(sel, factor1.3): psu _spec(sel, psu) if not psu or not psu.get(watt): return [] load 0 for k in (cpu, gpu): s _spec(sel, k) if s and s.get(tdp_w): load int(s[tdp_w]) need round(load * factor) if int(psu[watt]) need: return [Issue(error, PSU_UNDERPOWER, f整机估算 {load}W建议电源不低于 {need}W当前 {psu[watt]}W)] return [] RULES [rule_socket, rule_memory_type, rule_form_factor, rule_gpu_length, rule_psu_power, rule_cooler_height, rule_m2_slots, rule_cooler_socket, rule_gpu_connector] def check(sel): issues [] for fn in RULES: issues.extend(fn(sel)) # 规则之间互不依赖一条挂了不影响其他条 return issues关键设计有三点。Issue.code是稳定的机器码前端拿它去定位配件行、做国际化文案message只是兜底的人类可读描述两者不能混用。每条规则先判空再判值未选配件直接返回空列表避免「选到一半全是红字」的骚扰。字段缺失时返回 warn 而不是默默 return这一条是踩过坑的——早期版本写的是if not a or not b: return []结果后台导入时漏了插槽字段整套配置畅通无阻到装机台上才发现点不亮。3.3 前端分级error 禁用按钮warn 要求勾选确认后端返回的是一个 Issue 列表前端不能一股脑弹同一个红框。error 级别直接把「生成报价单」按钮置灰并滚到第一个出问题的配件行warn 允许提交但要在提交前弹一个确认框把风险写清楚客户点过「已知悉」才继续info 就挂在配件卡片角上不打断流程。这套分级的意义在于不把用户逼死。全是 error 的界面会让人放弃使用全是 warn 又等于没校验。经验是物理上装不进去、通电会烧的一律 error性能可能不达预期、体验可能打折的走 warn。3.4 校验的调用时机实时接口 提交前兜底校验接口做成POST /api/compat/check入参就是当前选配的 part_id 列表返回 Issue 数组。前端每次修改配置调一次做实时提示后端在保存配置单的接口里再调一次因为前端可以被绕过。两次调用逻辑共用同一份check()不要写两套——写两套的下场是某天改了规则只改了一边线上表现和测试环境对不上。请求体大致是这样八个分类的 id 传进来即可spec 由后端查库填充绝不能让前端把 spec 一起传上来否则规格可以被伪造校验等于没有{ cpu: 101, mainboard: 208, ram: 315, gpu: 402, ssd: 511, psu: 603, case: 701, cooler: 805 }4. 报价计算与配置单生成从成本价到客户手上那张单子算价这件事写错一个系数就是真金白银的损失而且错了不会报错只会安静地少赚或多报。这一章把价格口径、精度处理、快照落库和导出这条链走完。4.1 先把价格口径定死再写代码动手前必须把四个价格概念分清楚混在一起是这类系统最常见的返工原因名称含义存在哪成本价 cost进货价内部可见price_snapshot.cost售价 price对客户报价按加价率算出来price_snapshot.price服务费 service_fee装机、系统、走线的人工费build.service_fee成交总价 total明细小计 服务费落库冻结build.total加价率按成本分档这是门店的常见做法低价配件加价率高一点金额小客户不敏感高价配件加价率压下来金额大客户会比价。档位写在配置里而不是硬编码在函数里改价不用改代码。4.2 用 Decimal 算钱永远不要用 float0.1 0.2 ! 0.3不是段子报价单上少一分钱客户会问多一分钱财务会问。金额一律用Decimal数据库列用NUMERIC接口序列化成字符串传输。# app/pricing.py from decimal import Decimal, ROUND_CEILING # 分档加价率(成本下限, 加价率)从高到低匹配 TIERS [ (Decimal(8000), Decimal(0.08)), (Decimal(2000), Decimal(0.12)), (Decimal(0), Decimal(0.18)), ] def markup_rate(cost: Decimal) - Decimal: for floor, rate in TIERS: if cost floor: return rate return TIERS[-1][1] def unit_price(cost: Decimal) - Decimal: 成本 - 对外售价向上取整到 10 元避免 1999.00 这种想被砍价的尾数 raw cost * (Decimal(1) markup_rate(cost)) return (raw / Decimal(10)).to_integral_value(roundingROUND_CEILING) * Decimal(10) def build_total(items, service_feeDecimal(0)) - Decimal: # items: [{unit_price: Decimal, qty: int}, ...] sub sum((it[unit_price] * it[qty] for it in items), Decimal(0)) return sub service_fee参数上要注意ROUND_CEILING和ROUND_HALF_UP的区别向上取整保证不会因为抹零亏钱但如果业务要求「四舍五入到角」就换成quantize(Decimal(0.1), roundingROUND_HALF_UP)。这个选择必须写进需求文档不能让开发自己拍。另外sum()的初始值必须显式给Decimal(0)默认的整数 0 在空列表时会返回 int后续和 Decimal 相加虽然不报错但类型不一致容易在序列化时出问题。4.3 落库一次事务写完主单和明细价格当场冻结保存配置单不是简单的 INSERT要保证「主单、明细、单价快照」三者原子性。中途失败留下一个没有明细的空单导出时会直接崩。# app/service/build.py from decimal import Decimal from datetime import datetime def current_price(conn, part_id): 取生效时间不晚于当前时刻的最新一条价格 now datetime.now().strftime(%Y-%m-%d %H:%M:%S) row conn.execute( SELECT price FROM price_snapshot WHERE part_id? AND effective_at? ORDER BY effective_at DESC LIMIT 1, (part_id, now)).fetchone() if not row: raise ValueError(f配件 {part_id} 没有生效中的价格) return Decimal(str(row[0])) def save_build(conn, items, service_feeDecimal(0)): with conn: # 单事务主单 明细 总价更新全成或全败 sn B datetime.now().strftime(%Y%m%d%H%M%S) cur conn.execute( INSERT INTO build(sn, total, service_fee) VALUES(?,?,?), (sn, Decimal(0), service_fee)) build_id cur.lastrowid total service_fee for it in items: price current_price(conn, it[part_id]) # 冻结此刻价格 total price * it[qty] conn.execute( INSERT INTO build_item(build_id, part_id, qty, unit_price, part_name) VALUES(?,?,?,?,?), (build_id, it[part_id], it[qty], price, it[part_name])) conn.execute(UPDATE build SET total? WHERE id?, (total, build_id)) return sn, totalcurrent_price里effective_atnow这个条件就是价格历史表存在的全部理由它让「提前录入下月一号生效的调价」成为可能也让任何一张历史单都能查出当时的价钱。Decimal(str(row[0]))里的str()不能省SQLite 返回的是 float直接Decimal(float)会把浮点误差原封不动带进来。4.4 导出Jinja2 模板 WeasyPrint 出 PDF客户要的是能发微信、能打印的单子。做法是 HTML 模板渲染再转 PDF模板和网页共用一套数据改版式不用碰后端。# app/export/pdf.py from jinja2 import Environment, FileSystemLoader from weasyprint import HTML env Environment(loaderFileSystemLoader(templates)) def export_pdf(build, items, out_path): tpl env.get_template(quote.html) html tpl.render(buildbuild, itemsitems) # base_url 让模板里的相对路径 css/字体能被找到 HTML(stringhtml, base_urltemplates/).write_pdf(out_path) return out_path模板里金额统一走一个过滤器{{ %.2f|format(item.unit_price) }}别在模板里做运算。PDF 中文乱码是必踩的坑WeasyPrint 依赖系统字体容器镜像里没装中文字体就会出方块做法是在 CSS 里显式指定font-family: Noto Sans CJK SC, sans-serif;并在镜像里装对应字体包。数量上一张 A4 单子放 8 到 12 行明细最舒服超过就分页别硬挤。5. 排查清单价格不同步、PDF 乱码、锁表这五类问题怎么定位下面五条都是这套系统跑起来之后真实会遇到的按「现象 → 原因 → 解决」记遇到时按顺序对一遍比漫无目的地翻代码快得多。5.1 后台改了价前台还是旧价格现象运营在后台把某块主板从 899 改成 849刷新前台选配页价格纹丝不动重启服务才好。原因通常是两层缓存叠加应用层对配件列表做了进程内缓存为了少查库HTTP 层又加了Cache-Control。改价接口只更新了数据库两边都没失效。解决是把「价格变更」当成一个显式的失效事件改价成功后调用缓存清理函数同时给列表接口返回带版本号的 ETag。如果懒得做失效就把缓存 TTL 压到 30 秒以内别用「重启才生效」这种方案糊弄。5.2 兼容性没拦住报错列表是空的现象客户选了一套插槽明显不匹配的 CPU 和主板页面全绿直接生成了报价单。原因几乎都是规格字段为空导致规则提前 return。修法是给每条规则加「字段缺失返回 warn」的分支再在后台配件编辑页把该分类的必填 spec 键做成表单校验缺字段不允许保存。上线前跑一遍全量数据体检按分类统计 spec 里必填键的缺失数量缺失的配件先下架。5.3 导出的 PDF 中文全是方块现象本地开发好好的部署到服务器上导出的单子里中文全变成豆腐块数字和英文正常。原因是运行环境缺中文字体WeasyPrint 找不到字形就画方块。解法分两步镜像里装fonts-noto-cjk这类字体包CSS 里显式声明字体族并把sans-serif作为兜底。验证方法是导出一张含中文型号名的单子用pdffonts看一眼嵌入字体列表空的就是没生效。5.4 SQLite 报 database is locked现象几个人同时提交配置单偶尔有人收到sqlite3.OperationalError: database is locked。SQLite 默认是库级写锁写事务没结束其他写操作只能等等超时默认 5 秒就报错。短期解法是打开 WAL 模式并设置 busy_timeout长期解法是迁移到 MySQL 或 PostgreSQL。门店这种并发量WAL 加 3 秒超时足够撑住。import sqlite3 conn sqlite3.connect(data/build.db, timeout3) conn.execute(PRAGMA journal_modeWAL) # 读写不互斥显著减少锁冲突 conn.execute(PRAGMA synchronousNORMAL) # WAL 下兼顾安全与写入速度注意 WAL 模式要求数据库文件所在目录可写它会在旁边生成-wal和-shm文件只读挂载的容器里开不起来。5.5 合计金额和明细差一分钱现象明细逐条看得都对加起来的合计比手算少一分。原因基本是两个用 float 做累加或者在某一步单独做了四舍五入。修法是全链路 Decimal只在最终展示时格式化一次中间过程一律保留原始精度。另外检查build.total的写入是不是在循环里做了round()——有的话删掉让数据库存全精度值展示层再处理。6. 进阶价格生效时间与规则回归测试让系统改完不心虚这套系统上线后最容易被改坏的两处一是价格二是兼容性规则。价格改坏是钱的问题规则改坏是口碑的问题两者都需要在改动前有兜底。价格这块price_snapshot.effective_at已经支持未来生效可以利用它做「预约调价」运营一次性把下周的进货价批量导入生效时间填下周一零点系统到点自动切换不用半夜起来改库。配套要加一个校验——同一配件不允许出现两条生效时间完全相同的记录否则ORDER BY effective_at DESC LIMIT 1取到哪条全看数据库心情。加个唯一索引就能堵死CREATE UNIQUE INDEX uk_price ON price_snapshot(part_id, effective_at);。规则这块我习惯用固定样例做参数化回归。每次改规则先加一条用例跑不过就不许合并。# tests/test_compat.py import json, pytest from app.compat.rules import check def load_fixture(name): # fixtures/*.json 里存的就是一份选配 spec脱离数据库也能测 with open(ftests/fixtures/{name}.json, encodingutf-8) as f: return json.load(f) pytest.mark.parametrize(case, expect, [ (ok_build, []), (socket_am5_on_lga1700, [SOCKET_MISMATCH]), (ddr5_on_ddr4_board, [MEMORY_TYPE_MISMATCH]), (gpu_too_long, [GPU_LENGTH_EXCEED]), (psu_650_for_high_tdp, [PSU_UNDERPOWER]), ]) def test_rules(case, expect): sel load_fixture(case) codes [i.code for i in check(sel) if i.level error] assert codes expect # 顺序敏感规则注册顺序变了也要能立刻发现用例文件只存 part 的 spec 片段不连数据库跑起来是毫秒级提交前顺手敲一下pytest -q就行。断言写而不是in是为了让「多报了一条」也能被抓住——多报和漏报一样是事故前者逼得客户放弃使用后者把人送到装机台上。最后留一句我自己的习惯每次动价格口径或规则系数我都会先用一份固定的老配置单跑一遍把新旧总价并排打出来看差值确认差在预期范围内才提交。这套流程帮我拦下过好几次把 1.3 写成 1.03 的低级错误。希望帮到你。本文还有配套的精品资源点击获取