企业官网建设流程全解析

简介：韩枫自助装机和硬件报价系统是一套面向电脑装机店、硬件商家及经典ASP学习者的整站源码，可用于搭建配件查询、自选配置、今日报价与留言订购一体化的业务页面，解决配件报价、装机配置与订购信息分散管理的问题。压缩包共142个文件，平台标注大小0B，以asp动态页面和inc包含文件为核心，配合gif、jpg界面素材、css样式、mdb数据库及少量txt说明，目录结构较完整，便于按前台、后台模块拆解阅读。前台支持按CPU或主板自选配置并自动计算总价、生成机器ID，展示带价格波动的配件报价；后台设超级管理员、高级管理员与数据录入员分级权限，密码采用MD5加密，并提供数据库在线备份、恢复、压缩、SQL批量处理及新闻、产品、品牌管理。已有433人学习，适合研究ASP+Access整站开发、权限控制与硬件报价流程的读者参考。

1. 一套自助装机报价系统真正解决的是什么问题

上周帮朋友看一台机器：CPU 换了三代，主板跟着换，内存从 DDR4 挪到 DDR5，显卡长度又塞不进原来那个机箱。配件表在三个表格文件里来回改，改到第三版，客户手里的报价单和仓库里的实际拿货价已经对不上了。这种场面在电脑城柜台和校园装机社团里天天发生，靠表格能凑合，但只要同时维护十几张配置单，迟早翻车。

这份自助装机与硬件报价系统用的源码资料，定位很明确：它不关注电商前台堆砌商品详情页，核心是一个「配置单引擎」。配件库维护规格和价格，前台按分类自助选配，提交时执行兼容性校验、算总价、估功耗，最后保存成一张可打印、可追溯的报价单。它适合两类人：一类是做装机生意、需要一个内部报价工具的小团队；另一类是想找一个业务闭环完整、数据表设计不敷衍的源码来练手的开发者，因为这里包含分类树、规格校验、价格快照、事务处理，比增删改查的教学项目硬得多。

2. 技术栈与目录结构：从入口文件到模板层的落地路径

先把这套系统是怎么搭起来的说清楚。它追求的是便宜、好部署、改起来不费劲，不追求高并发。

2.1 技术选型：PHP + MySQL 在这类系统里为什么够用

这套系统的业务特征很鲜明：读多写少、数据量小（一个店铺几千条配件顶天）、后台表单密集、需要能扔到一台几百块的虚拟主机上就跑。按这个画像，常见做法是 PHP 7.x 配 MySQL 5.7 及以上，MVC 分层的单体应用，前端走服务端模板渲染加 Bootstrap 和 jQuery。我一般也会这么选，原因是三件事：表单页多，模板渲染比前后端分离少写一半胶水代码；部署只依赖运行环境和数据库，客户那边随便找个面板就能上传运行；二次开发门槛低，改个字段、加个导出，会 PHP 的人一上午就能上手。

反过来，如果硬上 Spring Boot 加 Vue 前后端分离，光是构建、跨域、静态资源托管就要折腾一轮，对一个只服务几个店员的小系统来说没有收益。这里要强调一点：选型只是权衡，与先进落后无关。真到了要接多门店、要跑报表、要做权限细分的阶段，再迁移也不迟，这套代码的分层还算干净，模型层抽出去并不难。

2.2 目录结构：一次请求从入口到模板的完整链路

目录组织是判断一套源码要不要接手的第一眼。这类系统的典型结构如下：

www/ ├── index.php # 唯一入口，所有请求都从这里进 ├── .htaccess # Apache 重写规则，隐藏 index.php ├── application/ │ ├── admin/ # 后台模块：配件录入、配置单管理 │ │ ├── controller/ │ │ ├── model/ │ │ └── view/ │ ├── home/ # 前台模块：选配、报价单展示 │ │ ├── controller/ │ │ ├── model/ │ │ └── view/ │ └── common/ # 公共层：基础控制器、服务类、验证器 │ ├── service/ │ └── validate/ ├── config/ │ ├── app.php # 应用配置：调试开关、默认模块 │ └── database.php # 数据库连接参数 ├── public/ │ ├── static/ # css / js / img │ └── uploads/ # 配件图片 ├── runtime/ # 缓存、日志、编译产物，必须可写 └── extend/ # 第三方扩展

这个结构里最值得关注的是application/common/service/这一层。很多人写 PHP 项目习惯把兼容性判断、价格计算直接塞进控制器，一个方法写到两百行，后面想复用就得复制粘贴。这套系统把「校验」和「算价」抽成 Service，控制器只负责收参数、调服务、返回视图，这个边界划得挺关键，二次开发时改动面会小很多。

runtime/是另一个容易忽略的目录。模板编译缓存、日志、session 文件默认都落在这里，权限没给够，表现就是首页白屏或者 500，而不是什么友好的报错。这是后面排查章节要重点讲的一条。

2.3 运行配置：数据库连接与伪静态

配置项集中在config/下，数据库这块是最常改的：

<?php // config/database.php return [ 'type' => 'mysql', 'hostname' => '127.0.0.1', // 建议写 IP，别写 localhost 'database' => 'pc_builder', 'username' => 'builder', 'password' => 'your_password', 'hostport' => '3306', 'charset' => 'utf8mb4', // 必须 utf8mb4，配件名里有表情符号和生僻字 'prefix' => 'hw_', // 表前缀，方便一套库跑多个站 'debug' => true, // 上线前记得关掉 ];

hostname写127.0.0.1而不是localhost，这是踩过坑的经验。MySQL 客户端在localhost时走 Unix socket，在127.0.0.1时走 TCP，两种路径对应的 socket 文件和端口配置可能不一致，报错还只给你一句「连接失败」。prefix配上hw_，后面所有 SQL 和模型都按这个前缀来，换部署环境不用改代码。debug在本地开着方便看堆栈，上线必须关，否则报错页会把库名和路径都吐出来。

伪静态是为了让 URL 变成/{模块}/{控制器}/{方法}的形式，Apache 下.htaccess大致是：

<IfModule mod_rewrite.c> RewriteEngine On RewriteBase / # 静态资源直接放行，别让请求打到框架 RewriteCond %{REQUEST_URI} !^/public/ RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php?s=$1 [QSA,PT,L] </IfModule>

Nginx 下等价的写法是在location /里加try_files $uri $uri/ /index.php?s=$uri&$args;。这段配置的作用就是：静态文件能直接命中就返回，命不中的统统交给index.php处理。配错了的典型症状是后台能进、前台图片全裂，或者反过来只有首页能开，一翻页就 404。

3. 数据表设计：四张主表撑起配件到报价单

数据库是这套系统的骨架，理解表关系比读控制器代码更重要。

3.1 分类、配件、配置单、明细四张表

核心表关系是「分类 1:N 配件」「配置单 1:N 明细 N:1 配件」。加上一张兼容性规则表，五张表就能把所有业务跑起来。

CREATE TABLE `hw_category` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `code` VARCHAR(32) NOT NULL COMMENT '英文标识：cpu / mainboard / memory', `name` VARCHAR(32) NOT NULL COMMENT '中文名：处理器 / 主板 / 内存', `sort` INT NOT NULL DEFAULT 0, PRIMARY KEY (`id`), UNIQUE KEY `uk_code` (`code`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='配件分类'; CREATE TABLE `hw_product` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `category_id` INT UNSIGNED NOT NULL, `brand` VARCHAR(32) NOT NULL, `model` VARCHAR(64) NOT NULL, `price` DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT '当前零售价', `cost` DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT '拿货价，前台不输出', `stock` SMALLINT NOT NULL DEFAULT 0, `attrs` JSON DEFAULT NULL COMMENT '规格参数：插槽、内存类型、长度、功耗', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1在售 0下架', PRIMARY KEY (`id`), KEY `idx_cat_status` (`category_id`, `status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='配件库'; CREATE TABLE `hw_config` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `sn` VARCHAR(32) NOT NULL COMMENT '配置单号，如 PC20240612001', `title` VARCHAR(64) NOT NULL, `total` DECIMAL(10,2) NOT NULL DEFAULT 0.00, `power` SMALLINT NOT NULL DEFAULT 0 COMMENT '估算整机功耗', `psu_advice` SMALLINT NOT NULL DEFAULT 0 COMMENT '推荐电源瓦数', `remark` VARCHAR(255) DEFAULT '', `created_at` DATETIME NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_sn` (`sn`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='配置单主表'; CREATE TABLE `hw_config_item` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `config_id` INT UNSIGNED NOT NULL, `product_id` INT UNSIGNED NOT NULL, `qty` SMALLINT NOT NULL DEFAULT 1, `price` DECIMAL(10,2) NOT NULL COMMENT '下单那一刻的价格快照', `name_snap` VARCHAR(96) NOT NULL COMMENT '名称快照，防配件被删后空白', PRIMARY KEY (`id`), KEY `idx_config` (`config_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='配置单明细';

这张设计里有三个决定值得说明。hw_product.attrs用 JSON 列存规格，后面小节展开。hw_product.cost是拿货价，前台模板绝对不能输出，这是商业数据。最要紧的是hw_config_item里的price和name_snap：明细表存的是价格快照，而不是靠product_id去关联配件表拿实时价。理由是报价单属于历史凭证，配件明天涨价，昨天发出去的报价单金额不该变。很多人图省事直接联表取价，线上就会遇到客户拿一周前的单子来对账，你说不清。

idx_cat_status这个联合索引是给前台选配页准备的，那个页面永远带着「分类 + 在售」两个条件查，加索引后几千条数据的列表页响应会明显好一截。

3.2 用 JSON 扩展列存规格，避开宽表陷阱

配件规格字段极不统一。CPU 要插槽、核心数、TDP；主板要插槽、板型、内存类型、内存插槽数；显卡要长度、厚度、供电接口、TDP；机箱要支持的板型、显卡限长、散热器限高。如果老老实实建宽表，最后会得到一张五六十列、八成字段是 NULL 的表，加一个新品类就得ALTER TABLE，改一次库提心吊胆。

用 JSON 列存，写进去长这样：

{ "socket": "LGA1700", "cores": 14, "tdp": 125, "mem_type": "DDR5" }

读的时候在 PHP 侧解一下就行：

// 取出后统一转成数组，避免到处 json_decode $product = Db::name('product')->where('id', $id)->find(); $product['attrs'] = json_decode($product['attrs'] ?: '{}', true); // 取规格时给默认值，防止某条数据录漏了字段导致校验逻辑报错 $socket = $product['attrs']['socket'] ?? '';

?: '{}'这段是必须的。JSON 列允许 NULL，历史数据里只要有一条是 NULL，直接json_decode(null)在部分版本会抛类型告警。

JSON 列的代价是没法直接建索引做范围查询。所以规则是：只把需要过滤和排序的字段做成实体列（分类、价格、库存、状态），其余规格一律进 JSON。这个项目里没有按「核心数大于 8」筛选的需求，所以没影响。如果以后真要做参数筛选，再针对高频字段补实体列和索引，比一开始就摊大饼稳妥。

3.3 后台录入到前台选配的数据流

把数据流串一遍，改代码时心里才有地图。后台录入配件：选分类、填品牌型号、填价格和库存、按分类动态渲染规格表单、提交后写hw_product。前台选配页：按hw_category.sort拿到分类列表，每个分类下列出在售配件，用户点选后前端即时把product_id收集起来。点「生成配置单」时，请求打到配置单控制器，控制器调服务层做校验和算价，通过后开事务写hw_config和hw_config_item两张表，返回配置单号。

这里有个交互细节值得学：前台选配不做整页刷新，选一个配件就发一次轻量请求，只返回「当前总价 + 当前兼容性提示」。用户选完 CPU 再选主板，插槽不匹配的警告立刻出现，不必等到最后提交才被一整屏红字打脸。这种做法的成本只是多几个 JSON 接口，体验差距很大。

4. 核心业务链路：保存、校验、估算三段代码

这一章是这套源码最值得读的部分，也是二次开发改动最集中的地方。

4.1 配置单保存：事务、价格快照与总价汇总

保存逻辑必须是事务的，主表和明细要么都进，要么都不进，否则会留下没有明细的无效配置单。

<?php // application/common/service/ConfigService.php class ConfigService { /** * 保存一张配置单 * @param array $items 形如 [['product_id'=>12,'qty'=>1], ...] * @param array $extra 标题、备注等 * @return string 配置单号 */ public function save(array $items, array $extra = []) { if (empty($items)) { throw new \Exception('请至少选择一个配件'); } Db::startTrans(); try { $total = '0.00'; $rows = []; foreach ($items as $item) { $p = Db::name('product') ->where('id', (int)$item['product_id']) ->where('status', 1) ->lock(true) // 行锁，防止并发扣库存时超卖 ->find(); if (!$p) { throw new \Exception('配件不存在或已下架'); } $qty = max(1, (int)$item['qty']); $line = bcmul($p['price'], (string)$qty, 2); // 金额用字符串精度 $total = bcadd($total, $line, 2); $rows[] = [ 'product_id' => $p['id'], 'qty' => $qty, 'price' => $p['price'], // 快照，不是引用 'name_snap' => $p['brand'] . ' ' . $p['model'], ]; } // 兼容性校验放在算价之后、写库之前 $check = CompatService::check($rows); $sn = date('Ymd') . str_pad( (string)(Db::name('config')->whereLike('sn', date('Ymd') . '%')->count() + 1), 3, '0', STR_PAD_LEFT ); $configId = Db::name('config')->insertGetId([ 'sn' => $sn, 'title' => $extra['title'] ?? '未命名配置单', 'total' => $total, 'power' => PowerService::estimate($rows), 'created_at' => date('Y-m-d H:i:s'), ]); foreach ($rows as &$r) { $r['config_id'] = $configId; } Db::name('config_item')->insertAll($rows); Db::commit(); return $sn; } catch (\Exception $e) { Db::rollback(); throw $e; } } }

这段代码有四个点值得看。lock(true)加的是SELECT ... FOR UPDATE，它保证了扣库存时不会有两个人同时读到同一份余量。金额用bcmul/bcadd而不是浮点加，是因为0.1 + 0.2 != 0.3在报价场景里会变成对不上账的实际事故。price存快照，前文已经说过原因。单号sn用「日期 + 当日序号」，简单但不保险——并发下单时两个请求可能算出同一个序号，靠uk_sn唯一索引兜底，插入失败会抛异常回滚，比生成一串看不懂的随机码方便人工对单。真要上生产，我会把它换成数据库自增 ID 加日期前缀，或者用 Redis 的INCR生成，把并发问题从源头消掉。

4.2 兼容性校验：规则表驱动的比对逻辑

兼容性判断写成硬编码的if-else也能跑，但每加一条规则就得改代码、重新发版。这个项目用一张规则表驱动：

CREATE TABLE `hw_compat_rule` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `code` VARCHAR(32) NOT NULL COMMENT '规则标识，如 cpu_socket_mb', `left_code` VARCHAR(32) NOT NULL COMMENT '左分类 code', `left_attr` VARCHAR(32) NOT NULL COMMENT '左规格字段名', `right_code` VARCHAR(32) NOT NULL, `right_attr` VARCHAR(32) NOT NULL, `operator` VARCHAR(8) NOT NULL DEFAULT 'eq' COMMENT 'eq / neq / lte', `level` TINYINT NOT NULL DEFAULT 1 COMMENT '1阻断 2仅警告', `message` VARCHAR(128) NOT NULL COMMENT '命中后的提示文案', PRIMARY KEY (`id`), UNIQUE KEY `uk_code` (`code`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='兼容性规则'; INSERT INTO `hw_compat_rule` VALUES (1,'cpu_socket_mb','cpu','socket','mainboard','socket','eq',1, 'CPU 插槽与主板不匹配，装不上'), (2,'mb_mem_type','mainboard','mem_type','memory','mem_type','eq',1, '主板不支持该内存类型'), (3,'mb_form_case','mainboard','form','case','support_form','eq',1, '机箱装不下该板型的主板'), (4,'cpu_tdp_cooler','cpu','tdp','cooler','max_tdp','lte',2, '散热器解热能力可能压不住这颗 CPU');

规则表把「谁和谁比、比哪个字段、什么条件下算错、错了说什么」全部数据化。第 4 条lte配level=2是个很实用的设计：散热器压不住 CPU 时，系统给警告但不拦着下单，因为确实有人愿意自己承担温度。这种「阻断 + 警告」分级的思路，比一刀切全拦下来让用户体验更好。

校验的实现：

<?php // application/common/service/CompatService.php class CompatService { private static $rules = null; private static function rules(): array { if (self::$rules === null) { self::$rules = Db::name('compat_rule')->select(); } return self::$rules; } /** * @param array $rows 明细，需带上分类 code 与 attrs * @return array 命中的问题列表 */ public static function check(array $rows): array { // 按分类建索引，一个分类只取一条，避免同分类选两件导致歧义 $map = []; foreach ($rows as $r) { $map[$r['category_code']] = $r; } $hits = []; foreach (self::rules() as $rule) { $left = $map[$rule['left_code']] ?? null; $right = $map[$rule['right_code']] ?? null; if ($left === null || $right === null) { continue; // 没选这类配件，跳过，不能误报 } $lv = $left['attrs'][$rule['left_attr']] ?? null; $rv = $right['attrs'][$rule['right_attr']] ?? null; if ($lv === null || $rv === null || $lv === '' || $rv === '') { continue; // 规格没录，宁可放过也不要瞎报错 } $pass = match ($rule['operator']) { 'eq' => (string)$lv === (string)$rv, 'neq' => (string)$lv !== (string)$rv, 'lte' => (float)$lv <= (float)$rv, default => true, }; if (!$pass) { $hits[] = [ 'level' => (int)$rule['level'], 'code' => $rule['code'], 'message' => $rule['message'], ]; } } return $hits; } }

self::$rules做了一次静态缓存，同一请求里多次校验不会重复查库。两个continue是这段代码的容错核心：少选配件不报错，规格没录入也不报错。后者听起来像偷懒，实际上是权衡——配件库刚建的时候规格一定录不全，如果严格报错，运营第一天就会被一堆误报烦到不敢用系统。等数据补全了，自然就全部命中校验。上线前我一般还会加一层：把「因为规格缺失而跳过」的规则记进日志，跑一周就能看出哪些配件的规格字段漏得最厉害。

4.3 功耗估算与电源推荐

功耗不是精确科学，但给一个大致数字能帮用户判断电源要不要加钱。

<?php // application/common/service/PowerService.php class PowerService { // 各分类的典型功耗缺省值，配件没录 tdp 时兜底 const BASE = [ 'cpu' => 95, 'mainboard' => 35, 'memory' => 6, 'ssd' => 7, 'hdd' => 10, 'gpu' => 180, 'fan' => 5, ]; public static function estimate(array $rows): int { $sum = 0; foreach ($rows as $r) { $code = $r['category_code']; if ($code === 'psu' || $code === 'case') { continue; // 电源和机箱不耗电 } $tdp = $r['attrs']['tdp'] ?? (self::BASE[$code] ?? 10); $sum += (int)$tdp * max(1, (int)$r['qty']); } // 加 30% 余量，再取整到 50 的倍数 $withBuffer = (int)ceil($sum * 1.3); return (int)(ceil($withBuffer / 50) * 50); } }

const BASE里的数值是经验缺省，不是厂商标称，实际用的时候可以按季节和具体配件调整。加 30% 余量是因为显卡和 CPU 的瞬时峰值功耗会明显高于 TDP，电源长期跑在满载临界点，故障率会上去。取整到 50 的倍数是为了对上市场主流瓦数，不推荐一个 437W 这种不存在的商品。

前台展示时，功耗和推荐的电源瓦数一起给出去，比单纯丢一个总价有理有据得多。这个小功能是很多装机工具忽略的，但用户很吃这套，因为它是「专业感」最廉价来源。

5. 本地跑通与常见问题排查：环境、建库、数据导入的踩坑记录

代码看懂之后，下一步是让它跑起来。这一章按顺序走一遍，末尾把高频问题集中列出来。

5.1 环境准备与建库

需要的环境不复杂：PHP 7.4 及以上（带pdo_mysql、json、mbstring、fileinfo扩展）、MySQL 5.7 及以上、Apache 或 Nginx 任选。本地用集成环境最省事，装完把站点根目录指到项目根（不是public/，这个项目的入口在最外层）。

建库只要一句：

CREATE DATABASE `pc_builder` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

utf8mb4和utf8mb4_general_ci这两个别改。配件名里出现品牌后缀的符号、或者中文标点的特殊字形，utf8三字节存不下会直接截断报错。

5.2 导入数据、设置后台入口

导入用命令行比图形工具稳：

# 注意显式指定字符集，否则中文会变成问号 mysql -u root -p --default-character-set=utf8mb4 pc_builder < install.sql

图形工具导入要留意两点：文件的编码必须是 UTF-8 无 BOM，BOM 头会被当成 SQL 语句的一部分，报语法错误；导入前先确认目标库的默认字符集已经建对，建错了之后改表也救不回来。

导入完成后改config/database.php的连接参数。后台入口一般是/admin，首次登录用安装脚本里写死的初始账号，登录后系统会引导改密码。:root目录的写权限要给足：

chmod -R 755 runtime public/uploads # 本地开发图省事可以 777，线上千万别

5.3 五条踩坑记录：现象、原因、解决

第一条：首页白屏或 500，日志目录里什么都没有。现象是浏览器一片空白，HTTP 状态 500，但runtime/log/下空无一物。原因是runtime/目录不可写，框架连日志都写不进去，错误被吞了。解决是先chmod -R 755 runtime并确认目录属主是运行用户（Apache 下常是www-data），再临时在入口文件顶部加ini_set('display_errors', 1); error_reporting(E_ALL);，让它把真实错误打到页面上，看到具体报错后立刻关掉。

第二条：数据库连不上，报错信息只有一句连接失败。配置里写的是localhost，而 MySQL 的 socket 路径和 PHP 里pdo_mysql.default_socket指的不是同一个位置。改成127.0.0.1走 TCP，问题立刻消失。如果换 IP 还连不上，再去确认端口有没有被防火墙拦、账号是否只允许localhost登录——GRANT时 Host 写成localhost的账号用127.0.0.1是登不进来的。

第三条：导入 SQL 报Unknown collation: 'utf8mb4_0900_ai_ci'。这是典型的版本错配：SQL 文件是从 MySQL 8.0 导出的，排序规则用了 8.0 新增的utf8mb4_0900_ai_ci，本地跑的是 5.7，不认。解决是文本编辑器全局替换成utf8mb4_general_ci，再导一次。反过来从 5.7 往 8.0 导一般没问题，8.0 向下兼容这些老排序规则。

第四条：后台能登录，一刷新就退回登录页。session 存不住。查三处：runtime/session目录是否存在且可写；config/app.php里的session.auto_start或 cookie 域配置是否和访问域名一致；如果前面挂了反向代理，检查是否透传了正确的 Host 头，cookie 域对不上，浏览器干脆不存。

第五条：配置单里的价格和配件库对不上。配件库调价之后，翻出旧配置单发现金额变了。原因就是明细存了product_id却没存价格快照，展示时联表取了实时价。按 3.1 和 4.1 的写法，明细表必须有price和name_snap两列并在保存时写入。已经上线的老数据要补，可以写一个一次性脚本，把hw_config_item的price按当时的created_at从历史价格表回填，没有历史价格表就只能按现状固化，然后在配置单上标注「价格为生成时快照」。

6. 二次开发：把它改成自己业务里能用的报价工具

这套代码直接拿来卖机器不一定合身，但作为底座改造的性价比很高。我的思路是先从「数据」动手，再动「流程」，最后才碰「界面」，顺序反了会做大量无用功。

第一步改分类和规格字典。不同业务的配件体系差别很大，做整机的人要 CPU、主板、显卡，做监控工程的人要摄像机、录像机、硬盘。改法是先在hw_category里增删分类，再整理一份各分类的规格字段清单，写进后台录入页的动态表单配置。这份清单建议单独放一个 PHP 数组文件，别散在模板里：

<?php // config/spec_schema.php return [ 'cpu' => [ 'socket' => ['label' => '插槽', 'type' => 'select', 'options' => ['LGA1700','AM5','AM4']], 'tdp' => ['label' => '功耗(W)','type' => 'number'], 'mem_type' => ['label' => '内存类型','type' => 'select', 'options' => ['DDR4','DDR5']], ], 'gpu' => [ 'length' => ['label' => '长度(mm)', 'type' => 'number'], 'tdp' => ['label' => '功耗(W)', 'type' => 'number'], 'power' => ['label' => '供电接口', 'type' => 'text'], ], ];

后台渲染表单、前台展示规格、校验服务读字段名，三处都吃这份配置，加字段只改一处。这是我在这类项目里最推荐的一个小重构。

第二步改规则表。把hw_compat_rule当配置文件用，新增机型、新增品类只需要INSERT，不用发版。改造时建议给规则加一个enabled字段，出问题能快速摘掉某条规则而不删数据。

第三步才动界面和输出。报价单导出 PDF 或 Excel 是最常见的需求，别在控制器里拼 HTML，抽一个独立的导出服务，把配置单号和模板路径当参数传进去。这样以后加微信分享、加二维码，都是同一份数据换一种渲染。

验证方法很简单：造三张单子——一张全兼容的、一张插槽冲突的、一张显卡塞不进机箱的——跑一遍保存流程，看阻断和警告是否按level分开提示，再看配件库改价后老单子金额是否纹丝不动。这三条过了，改造基本是安全的。

血泪经验是：改造之前先给hw_product.attrs和hw_compat_rule各导一份 JSON 备份。我见过有人为了加一个字段直接ALTER TABLE改结构，结果规格字段名对不上，历史配件的校验全部静默跳过，表面上系统一切正常，实际兼容性检查形同虚设——这种「静默失效」是最难发现的一类问题。从那以后我每次动规格结构，都会先跑一遍全量配置单的校验结果做前后对比，差异必须能解释清楚才继续。希望这份源码能帮你少走几步弯路。

本文还有配套的精品资源，点击获取