简介面向电脑装机门店、硬件报价网站搭建者及ASP初学者的一套自助装机与配件报价系统源码可用于快速搭建前台选配、报价展示和后台管理的整站流程。前台支持按CPU或主板型号自动搭配主机、实时计算总价并生成机器ID配合今日报价的价格波动展示与带订购信息的留言模块形成从选配到询价的闭环。压缩包共142个文件以51个ASP动态页面、16个INC公共包含文件、1个MDB数据库和CSS样式为主另有GIF、JPG界面素材及少量TXT说明包大小字段显示为0B实际以下载页为准。后台提供超级管理员、高级管理员和数据录入员的分级权限密码经MD5处理并集成数据库在线备份恢复压缩、SQL批量处理以及新闻、产品、品牌和配件报价管理。已有433人学习适合参考ASPAccess的目录组织、角色权限与报价业务实现。1. 自助装机和硬件报价系统客户自己选配店员只负责核单某装机店的老板跟我吐槽过一件事店里三个人各维护一份 Excel 配件价目表客户在微信里问「这套配置多少钱」店员得挨个查价、加总还得凭经验判断主板和 CPU 对不对得上来回折腾半小时。后来他们换成一套自助装机和硬件报价系统客户在页面上自己点 CPU、主板、内存价格实时跳装不上的组合直接标红拦住最后生成一张能转发给朋友的配置单。这套源码落地的就是这条链路配件库维护、自助选配、兼容性校验、实时报价、配置单分享后台一份价格数据全店共用。它适合两类人——中小装机商、电脑店、硬件工作室想要一个价格和配件库都能自己改的报价工具以及开发者想找一个「规则校验 价格体系 前后端联动」都齐全的中型业务项目练手比增删改查的 Demo 有嚼头得多。2. 技术栈与目录结构配件、配置单、报价三条线怎么切先给结论这类系统最怕的不是并发是配件字段天天变。CPU 要插槽、核心数、TDP显卡要长度、厚度、供电口内存要代别、频率、时序你今天用关系表的列固定下来下个月上新品类就得改表。所以整套设计的重心是把「稳定字段」和「差异字段」分开。下面按这个思路讲选型和分层常见做法是后端 Spring Boot MyBatis-Plus MySQL前端 Vue3 Element Plus前后端分离部署。2.1 技术选型为什么是 Spring Boot MyBatis-Plus Vue3后端选 Spring Boot 的理由很实在配件库、价格策略、规则校验这些东西都是典型的业务代码Spring 的依赖注入能让「一条兼容性规则一个类」这种写法非常自然规则类加个Component就进容器了规则链靠ListCompatibilityRule注入自动收集不用维护注册表。MyBatis-Plus 提供分页和条件构造器配件库那种「按分类 品牌 价格区间 是否上架」的动态筛选用LambdaQueryWrapper拼起来比手写 XML 舒服。MySQL 8 在这套系统里有个关键作用原生 JSON 字段。配件差异规格直接塞 JSON 列查询时用JSON_EXTRACT或-取值既不用为每个品类建一张表也不至于把规格拼成字符串解析。这一条是整个数据模型的支点后面第 2.3 节会展开。前端 Vue3 Element Plus 的考虑是后台管理页面密度高配件列表要带批量操作、价格导入要弹窗上传、配置单查询要展开行显示明细Element Plus 的 Table、Form、Cascader 基本能覆盖九成场景省下来的时间全砸在选配页的联动逻辑上。状态管理用 Pinia 存当前选配上下文选配页刷新要能恢复现场这一点比想象中重要——客户选到一半手滑刷新上下文没了会直接跑单。选配页本身不强依赖 SSR因为价格和库存都是实时的SEO 价值也不高所以纯 SPA 部署就够了。如果你的场景是公开报价页要给搜索引擎抓那就换成 Nuxt 或加一层预渲染但报价准确性优先于抓取覆盖率这是我踩过之后的判断。2.2 目录结构配件域、配置单域、报价域三块切开后端按业务域分包不按 Controller/Service/Mapper 三层平铺。平铺的问题是配件、配置单、报价三个域的 Service 混在一个包里改报价要翻半天文件按域分包后每个目录自成闭环新人接手看目录就知道系统在做什么。目录职责关键类part/配件库分类、配件、规格模板、批量导入PartController、PartSpecTemplatebuild/选配选配上下文、联动候选、配置单落库BuildController、ConfigContextrule/兼容性规则链插槽、内存代别、尺寸、功耗、数量CompatibilityRule及实现类quote/报价有效价、阶梯价、优惠、快照QuoteService、PricePolicycommon/统一返回、异常、缓存键、Base62 短码Result、CacheKeys前端目录按页面切views/build/选配页、views/admin/part/配件管理、views/admin/quote/报价与配置单组件层单独抽components/PartPicker.vue选配页和后台预览共用同一个选择器避免两处逻辑漂移。这个拆分不是洁癖是因为选配页和后台预览的过滤规则必须完全一致一旦复制两份代码早晚会出现「后台能选、前台不能选」的灵异现象。2.3 建表配件主表 规格 JSON少改一半的表核心就四张表配件主表、配置单表、配置单明细表、价格历史表。配件主表只放所有品类都有的字段差异规格进 JSON 列。CREATE TABLE part ( id BIGINT PRIMARY KEY AUTO_INCREMENT, category_id BIGINT NOT NULL COMMENT 所属分类如 CPU/主板/显卡, brand VARCHAR(64) NOT NULL, model VARCHAR(128) NOT NULL, spec JSON NOT NULL COMMENT 差异规格键名由分类模板约束, cost_price DECIMAL(10,2) NOT NULL COMMENT 进价仅后台可见, sale_price DECIMAL(10,2) NOT NULL COMMENT 标准售价, stock INT NOT NULL DEFAULT 0, status TINYINT NOT NULL DEFAULT 1 COMMENT 1 上架 0 下架, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_cat_status (category_id, status) ) COMMENT配件主表;spec里 CPU 长这样{socket:AM5,tdp:105,cores:8}主板长这样{socket:AM5,memType:DDR5,maxCoolerHeight:160}。规则校验时用spec-$.socket取值或者查出来后在 Java 里读成 Map看性能取舍——候选件数量小一个分类通常几十到几百条一次性查出来在内存里判断更快也省得 SQL 里写一堆 JSON 路径。配置单明细表里我坚持存一份quoted_price快照而不是只存part_id靠实时算。原因第 5 章会细说简单讲客户三天后拿着分享链接来店里对账价格变了就是纠纷。CREATE TABLE config_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, sheet_id BIGINT NOT NULL, part_id BIGINT NOT NULL, quantity INT NOT NULL DEFAULT 1, quoted_price DECIMAL(10,2) NOT NULL COMMENT 加入配置单那一刻的有效价快照, KEY idx_sheet (sheet_id) );价格历史表按part_id 生效时间存改价时插入一条新记录而不是原地覆盖sale_price只是当前生效价的一个冗余方便查询。这样做的好处是三个月后老板问「这颗 U 上个月卖多少」你能直接查出来坏处是表会涨按配件数量级算一年也就几十万行不叫事。3. 兼容性校验一条规则一个类把「装不上」挡在下单前兼容性校验是这套系统的灵魂也是最容易做成 if-else 泥潭的地方。我的做法是把每条规则独立成类实现统一接口靠 Spring 自动收集成链。规则要能单独开关、单独定位报错前端才能精确地在某个配件上标红而不是甩一句「配置不兼容」让客户自己猜。3.1 规则接口与上下文所有规则吃同一份数据规则统一入参是一个ConfigContext里面是「分类 - 已选配件列表」的映射加上一个可选的候选件。规则只从上下文取数据不碰数据库这样规则可以做单元测试也能在候选过滤和整单校验两个场景复用。public interface CompatibilityRule { /** 规则编码前端用它定位标红位置也用于后台开关 */ String code(); /** 返回 empty 表示通过返回文本表示不兼容原因直接展示给用户 */ OptionalString check(ConfigContext ctx); /** 默认中优先级数字小的先跑命中即短路 */ default int order() { return 100; } }code()是给前端用的比如CPU_MAINBOARD_SOCKET前端拿到这个编码就知道该把红框画在主板那张卡上。order()决定执行顺序插槽这种硬冲突排前面命中就返回不用再跑后面的功耗、尺寸规则省一次计算也省一条更让人困惑的报错。ConfigContext的两个方法值得单独说first(分类)取该分类的第一个配件optional(分类)返回Optional。后者用于「可能没选」的场景——客户还没选显卡功耗规则就不该报错也不该按独显去推电源。3.2 一条具体规则CPU 插槽匹配看最典型的一条。CPU 和主板的插槽必须一致这是个硬约束错了根本点不亮。Component public class CpuMainboardSocketRule implements CompatibilityRule { Override public String code() { return CPU_MAINBOARD_SOCKET; } Override public int order() { return 10; } // 硬冲突最先跑 Override public OptionalString check(ConfigContext ctx) { Part cpu ctx.first(CPU); Part board ctx.first(MAINBOARD); // 有一方没选就不校验避免未选完就满屏红 if (cpu null || board null) return Optional.empty(); String cpuSocket cpu.specText(socket); String boardSocket board.specText(socket); // 规格缺失时不能静默放行要提示人工确认 if (cpuSocket null || boardSocket null) { return Optional.of(插槽信息缺失请人工确认兼容性); } if (!cpuSocket.equalsIgnoreCase(boardSocket)) { return Optional.of(CPU 插槽 cpuSocket 与主板插槽 boardSocket 不匹配); } return Optional.empty(); } }specText(socket)是Part上的一个小工具方法从 JSON 里按 key 取值并做空安全。这里有个细节值得说规格缺失时我返回的是「请人工确认」而不是Optional.empty()。早期的版本就是缺失当通过结果一批没录插槽字段的老配件全被放过去了客户配了套点不亮的机器退货加差评。宁可多一次人工确认也不要静默放行——这是血泪教训。3.3 功耗估算与电源推荐余量留多少才合适功耗规则分两半一半是校验客户选的电源瓦数够不够一半是推荐没选电源时给个建议值。两半共用同一个估算方法。public int estimateWatts(ConfigContext ctx) { int cpuTdp ctx.optional(CPU).map(p - p.specInt(tdp, 65)).orElse(65); int gpuTdp ctx.optional(GPU).map(p - p.specInt(tdp, 0)).orElse(0); int base 60; // 主板 内存 固态 风扇的粗略基数 // 按整机峰值负载的 30% 留余量再向上取整到 10W int peak cpuTdp gpuTdp base; int withHeadroom (int) Math.ceil(peak * 1.3 / 10.0) * 10; return withHeadroom; }参数说明tdp缺失时 CPU 按 65W 兜底显卡按 0无核显的机器没选显卡时估算值会偏保守但至少不会给出一个明显不够的电源。base取 60W 是个工程经验值实际装机里主板加两三条内存加一块固态加几个风扇峰值确实在这个量级。余量取 30% 而不是 20%是因为电源的额定功率在高温下会缩水而且客户后面可能加显卡。这里翻过车早期余量给 10%一台 i7 加中端卡的机器推荐了 550W 电源客户满载跑渲染偶尔重启回来找售后。余家余量这件事宁可推荐大一点也别踩线。这条规则我后来固定成「估算值 30%且不低于 450W」才收手。4. 选配与报价链路从点击 CPU 到生成一张可分享的配置单规则讲完了看数据怎么走。选配页一次点击会触发两件事过滤候选哪些还能选、重算价格现在多少钱。这两件事的性能和正确性决定了客户会不会中途关页面。4.1 候选过滤每选一个件都要重跑一次局部校验客户在「内存」分类里看到的列表必须是「和已选主板兼容的那些」。做法是把每个候选件塞进上下文跑一遍规则通过的才返回。这叫局部校验和整单校验的区别是整单必须全部通过才允许生成配置单局部只要不冲突就能展示。GetMapping(/api/build/options) public ResultListPartVO options(RequestParam Long categoryId, RequestParam(required false) ListLong selectedIds) { // 1. 用已选配件还原上下文selectedIds 来自前端服务端要按 id 重新查库校验 ConfigContext ctx buildService.loadContext(selectedIds); // 2. 拉取该分类下所有上架且有库存的配件 ListPart candidates partService.listOnSale(categoryId); // 3. 逐个塞进上下文跑规则冲突的直接过滤掉 ListPartVO result candidates.stream() .filter(p - ruleEngine.checkPartial(ctx.withCandidate(categoryId, p)).isEmpty()) .map(p - PartVO.of(p, priceService.effectivePrice(p.getId(), ctx.channel()))) .collect(Collectors.toList()); return Result.ok(result); }关键参数selectedIds必须由服务端重新查库不能信前端传来的完整对象——前端可以改价格。ctx.channel()是渠道标识门店 / 线上 / 批发有效价按渠道不同这个后面说。withCandidate返回一个新的上下文副本不是修改原对象避免流式处理时互相污染。还有一个必须处理的问题候选列表会越选越少。客户先选了个 mATX 主板再去看机箱发现只剩三款能选体验上会觉得「怎么东西这么少」。我的处理是在返回结果里带上被过滤掉的数量和被哪条规则过滤的前端在上方显示一行灰字「已按主板尺寸过滤 12 款」。不显示的原因很简单客户会怀疑系统坏了。4.2 报价计算叠加顺序错了金额差一块钱价格体系不复杂但有严格的叠加顺序逐件有效价 → 汇总小计 → 渠道阶梯 → 整单优惠 → 最后一步才四舍五入。顺序一旦搞反金额就会差几分到几块对账的时候特别难受。public BigDecimal quote(ConfigContext ctx, QuoteOptions opt) { // 1. 逐件取有效价可能来自渠道价 / 促销价 / 标准价不做舍入 BigDecimal subtotal ctx.parts().values().stream() .flatMap(List::stream) .map(p - priceService.effectivePrice(p.getId(), opt.getChannel())) .reduce(BigDecimal.ZERO, BigDecimal::add); // 2. 渠道阶梯满额返点按小计匹配档位 BigDecimal afterTier tierPolicy.apply(subtotal, opt.getChannel()); // 3. 整单优惠券 / 活动按金额或百分比扣减 BigDecimal discount discountPolicy.apply(afterTier, opt); // 4. 只在最终结果上舍入且不允许为负 return afterTier.subtract(discount) .max(BigDecimal.ZERO) .setScale(2, RoundingMode.HALF_UP); }参数说明effectivePrice内部按渠道 - 当前时间 - 是否促销三级取价取到就返回命中缓存。tierPolicy.apply是阶梯策略配置在数据库里而不是写死老板改返点规则不用发版。max(BigDecimal.ZERO)是防御优惠券叠加算出来负数时要兜住否则会出现「这单倒找钱」的离谱账单。四舍五入只放在最后一步是因为每件单独setScale(2)会把误差累加十几件的配置单能差出几毛钱。这个问题对个人客户无所谓对批发客户就是账目对不上的由头。4.3 配置单落库与分享码客户点「保存配置」后端把明细连同当时的有效价一起写进config_item同时生成一个短码。短码用 Base62 加唯一索引长度 6 位足够生成时查一次冲突重试即可不要用自增 ID 直接暴露——那等于把「这家店昨天卖了几单」写在 URL 上。分享出去的页面读的是配置单快照价格就是快照里的quoted_price同时展示「报价有效期至 X 日」。有效期是我后来加的一开始做成永久有效结果有客户拿三个月前的分享链接来店里要求按老价成交谈得很不愉快。有效期设 7 天到期后页面提示「请联系店员重新报价」把主动权收回来。5. 避坑与排查上线后最常被追问的五个问题下面五条全是真实会被问到脸上的按「现象 → 原因 → 解决」写能对号入座就直接抄。5.1 兼容性相关的三个坑坑一选配页不拦提交时才报错。现象是客户选了 DDR5 内存配 DDR4 主板选配页面上毫无提示点了保存才弹出一句「配置不兼容」客户直接骂人。 原因是规则只在生成配置单时跑全量校验/api/build/options那个候选接口没接规则引擎。 解决是把引擎拆成checkPartial和checkFull两档局部校验用于候选过滤和每次变更的实时提示全量校验用于最终提交。两档共用同一套规则类只差「未选中的分类是否跳过」这一个参数。坑二散热器高度超限规则没触发。现象是 165mm 的风冷塞进限高 160mm 的机箱系统显示兼容。 原因是规格字段名不统一散热器录的是height机箱模板里定义的是maxCoolerHeight规则取maxCoolerHeight时散热器那边取到 null被当成「无法判断」放行了。 解决是给每个分类定义字段模板part_category.spec_templateJSON录入时按模板校验键名和单位规则里取不到值一律走「需人工确认」分支。字段名的事必须在录入环节卡死靠规则层兜不住。坑三内存插槽插满四条还能继续加。现象是客户选了 4 条内存页面依然允许再加第 5 条只是价格往上走。 原因是当时只做了兼容性校验没做数量约束规则层默认「同一分类可以任意多件」。 解决是补一条QuantityRule按分类模板里的maxQty校验主板类maxQty1内存类按主板规格里的memSlots动态取值。数量约束和兼容性约束是两码事最好一开始就分开建模。5.2 价格与数据同步的两个坑坑四后台改完进价前台客户刷新还是老价。现象是老板在后台把某款显卡调价 200前台刷新好几次价格纹丝不动重启服务才好。 原因是配件列表整体做了缓存缓存 key 只带分类 ID改价时只清了「按 ID 查单件」的缓存没清列表缓存。 解决是把价格从列表缓存里剥出来列表只缓存「有哪些配件」价格走独立的effectivePrice缓存key 带上part_id 渠道 价格版本号改价时递增版本号旧 key 自然失效。这个改法比全量清缓存精准也不会因为一次改价把整个列表打穿。坑五分享出去的配置单过几天价格变了。现象是客户拿着上周的分享链接来店里说好的八千三你算出来八千六客户觉得被坑。 原因是配置单只存了part_id页面每次打开都按实时价重算。 解决是落库时把quoted_price快照写进明细表分享页优先读快照同时展示有效期。改价本身没错错在让客户看到的价格在背后偷偷变。快照这件事一定要在第一次上线就做后面补的代价是迁移历史数据。6. 二次开发加一个配件分类接一路外部价格源这套系统最容易被改的地方是配件分类。硬件圈子品类一直在变今天加显示器明天可能加外设、加整机所以分类和规格模板必须是数据驱动的不能写死在代码里。6.1 加一个「显示器」分类要动哪几处理论上有三步插分类记录、定义规格模板、加一条前端 tab。如果代码写得对Java 侧一行不用改。-- 1. 新增分类spec_template 约束该分类允许出现的规格键 INSERT INTO part_category (code, name, spec_template, max_qty, sort) VALUES (MONITOR, 显示器, JSON_OBJECT( size, JSON_OBJECT(type,number,unit,inch), resolution, JSON_OBJECT(type,string), panel, JSON_OBJECT(type,string,enum,JSON_ARRAY(IPS,VA,TN,OLED)), refresh, JSON_OBJECT(type,number,unit,Hz), interface, JSON_OBJECT(type,string) ), 1, 90);spec_template干了三件事约束键名不许乱起名、约束类型和单位不许把27和27寸混着录、约束枚举面板类型只能是那四个值。max_qty1表示一台机器只装一台显示器数量规则自动生效。前端加一个 tab 是纯配置选配页的分类列表从/api/part/categories拉。规则层要不要加显示器对整机兼容性几乎没有硬约束加一条分辨率与显卡的「建议」规则就行走警告级别而不是拦截级别——警告和拦截要分开全都拦截会让客户什么都选不了。验证方法很土但有效拿三条真实配件录进去故意把refresh录成字符串165Hz看后台是否报类型错误再故意把面板类型录成PLS看枚举校验是否拦住。两个都拦住说明模板校验真的接上了。6.2 接外部价格源先落历史表别直接覆盖售价二次开发里最常见需求是「同步电商平台的行情价」。直接定时覆盖sale_price是灾难因为行情价和你店里的定价策略是两回事行情涨了不代表你要立即涨。我的做法是分三层拉取写price_history的sourceEXTERNAL记录跟当前sale_price做差异对比超过阈值比如 5%才在后台生成待审核提醒人工确认后再改售价。Scheduled(cron 0 30 3 * * ?) // 每天凌晨 3:30 跑避开营业时段 public void syncExternalPrice() { ListExternalPrice fetched fetchClient.pull(); // 外部数据源失败抛异常 for (ExternalPrice ep : fetched) { Part part partService.getBySku(ep.sku()); if (part null || part.status() 0) continue; // 没匹配上或已下架跳过 BigDecimal diff ep.price().subtract(part.salePrice()) .abs().divide(part.salePrice(), 4, RoundingMode.HALF_UP); // 差异超 5% 才生成待办避免每天几十条无意义提醒 if (diff.compareTo(new BigDecimal(0.05)) 0) { alertService.createPriceAlert(part.id(), ep.price(), diff); } // 无论是否超阈值都记一条历史后面能看趋势 priceHistoryService.append(part.id(), ep.price(), EXTERNAL); } }参数说明cron放凌晨跑是因为抓取会占带宽也不影响营业compareTo(new BigDecimal(0.05))是阈值判断用compareTo而不是equalsBigDecimal 的equals会把0.05和0.050判成不等这是个经典陷阱。append无论是否超阈值都要写历史数据不写就没有趋势光看当前价说明不了什么。验证这套同步是否正常我一般盯三个点一看price_history当天是否有新增记录说明任务跑了二看sourceEXTERNAL的记录里 SKU 匹配率低于 80% 说明外部源的 SKU 规则变了三看待办列表里是否有明显不合理的价差超过 50% 基本是数据源标错价别急着跟。从那以后我每次接外部数据源都强制走一遍「先落历史、再对比、人工确认」这三步哪怕客户催着要自动改价也不松口。自动改价省下的人力远不够填一次错价的坑。这套系统的分类模板和规则链设计我后来在自己做的几个报价类项目里都照搬了改起来确实省心。希望帮到你。本文还有配套的精品资源点击获取
