Starsoup Docs

Appearance

Crystal ERP ↔ 独立站 (benedeca-select) 融合审计与预警报告 ​

生成日期: 2026-03-09 目标项目: Crystal ERP (Vue+Supabase) 与 benedeca-select-web (Next.js+Neon) 核心原则: ERP 作为唯一权威数据源 (Source of Truth)，1 SKU = 1 唯一实物。

摘要 (Executive Summary) ​

鉴于目前 ERP 处于主力开发阶段，且商业化路线图为 “优先打通 Etsy -> 其次融合独立站”，这是一个非常务实且能快速带来现金流的策略。 然而，由于水晶原石“一物一码”的孤品特性，独立站如果按照传统电商平台（如 Shopify）的逻辑构建，将在未来与 ERP 对接时产生严重的架构冲突。本报告提炼了你提到的 3 个核心痛点，并挖掘了 5 个你可能尚未注意到的系统盲区，为将来的“大改动”提供防坑指南。

1. 媒体与图片资产管理 (Media Assets) ​

现状痛点 (你提到的点 1)： ERP 目前为控制免费 R2 额度，限制单图 2MB，且仅为“库存入库照”，缺乏面向消费者的多角度、高精度产品图。

审计盲区与未来建议：

  • 盲区：图片职责混淆。 内部清点库存用的照片（带卡尺、标签）和外部营销用的照片（打光、造景）用途完全不同。
  • 解决方案 (ERP 侧改造)：未来 ERP 的 inventory_items 需要分离 inventory_image (单张，入库凭证) 和 marketing_images (多张 JSON 数组，展示用)。
  • R2 免费额度优化策略：Cloudflare R2 免费额度是 10GB/月。如果要存高清图，绝对不能存原图。ERP 在前端上传图片至 R2 前，必须引入浏览器端压缩（如 browser-image-compression），将图片强制转换为 WebP 格式。一张 4K 高清 WebP 仅需 200-400KB。这样 2MB 限制可以轻松塞下 5-8 张高清商品图，完美解决独立站展示问题。

2. 商品数据流与“主数据”割裂 (Master Data Mapping) ​

审计盲区与未来建议：

  • 盲区：营销文案算谁的？ 独立站的 Prisma schema 中包含了 descriptionZh, category, crystal 等面向用户的介绍和 SEO 词汇。但在 ERP 中，商品可能只有 origin, weight, batch 等物理属性。
  • 防坑指南：将来独立站的商品展示，到底是全盘拉取 ERP？还是 ERP 只推物理数据，营销文案在独立站后台写？
    • 建议架构：ERP 仅作为“物理事实库”（重量、成本、是否售出）。未来需要开发一个 API Adapter (映射中间层) 或者在独立站建立一个 PIM (产品信息管理) 模块，当 ERP 推送过来一个新 SKU 时，独立站运营人员在独立站后台为这个 SKU 补充漂亮的故事和文案，而不是把所有营销长文本都塞进轻量级的 ERP 数据库里。

3. 极高风险：超卖与购物车并发抢单冲突 (Race Conditions) ​

审计盲区与未来建议： 因为 1 SKU = 1 原石（没有库存深度的概念）。

  • 盲区：多渠道并发冲突。 假设同一块绝版紫水晶，客户 A 在 Etsy 放进购物车，客户 B 在你的独立站准备付款。如果同时结账，谁能买到？
  • 防坑指南：引入“库存锁定锁 (Inventory Lock)”机制。
    • 独立站（以及未来的 Etsy）在用户将商品加入购物车并进入 Check-out（结账）页面时，必须通过 API 向 ERP 发送一个 "Lock" 请求。
    • ERP 将该 SKU 状态暂时变更为 locked，锁定 15 分钟。15 分钟内未支付，释放回 available。
    • 独立站的 Product 表中的 stock 字段实际上可以废弃，改为布尔值 isAvailable，完全跟随 ERP 的 webhook 广播。

4. 支付与登录系统集成 (Auth & Payments) ​

现状痛点 (你提到的点 3)： 独立站将来需要做用户登录和支付系统。

审计盲区与未来建议：

  • 盲区：订单状态的“双重事实”。用户在独立站用 Stripe / PayPal 支付成功后，独立站的订单状态变成 Paid，但如果此时由于网络波动，未能通知到 ERP 生成 sales_records，账就乱了。
  • 防坑指南：
    • 支付集成：支付网关（如 Stripe）的 Webhook 应该成为驱动力。Stripe 扣款成功 -> 独立站收到 Webhook -> 独立站调用 ERP API 写入销售记录 -> ERP 返回成功 -> 独立站更新自己的 DB。必须确保这个链条的强一致性（引入重试机制）。
    • 用户登录：独立站目前预留了 User 表。由于 ERP 用的是 Supabase Auth，如果你希望未来打通会员体系，独立站其实也可以直接接入 Supabase Auth 代替 NextAuth/Neon 原生 Auth，这样你所有的用户资产（员工、客户）都在一个身份验证池子里，方便管理。

5. 路线图节奏与独立站重构预警 (Roadmap Alignment) ​

现状痛点 (你提到的点 2)： 优先打通 Etsy，独立站先放着，未来将面临大改。

审计盲区与未来建议：

  • 盲区：独立站越写越深，未来重构成本极高。 如果你现在花大量时间在独立站写“购物车状态管理”、“商品上下架逻辑”，等 Etsy-ERP 链路跑通后，这些代码 80% 都要重写，因为逻辑全变了。
  • 防坑指南（强烈建议的开发节奏）：
    1. 当前阶段（独立站）：把独立站当成一个纯展示型 CMS + 博客 (Blog)。专心写 SEO 文章（利用好 BlogPost 表），商品暂时放几张精选图，放个 "Buy on Etsy" 的跳转按钮。绝对不要现在去写购物车和支付模块。
    2. 中期阶段（ERP 侧）：全力集中于 ERP 的标签打印 (dtpweb)、Etsy OAuth 和 Etsy 订单回拉。
    3. 最终阶段（独立站重构）：等 ERP 能够完美控制 Etsy 后，ERP 的 API 接口也就自然成型了。此时再回到独立站，把 "Buy on Etsy" 换成原生购物车，接入 Stripe，并通过已经成熟的 ERP API 走下单逻辑。这样重构的痛苦最小。

总结行动项 (Action Items) ​

  1. 修改 R2 上传逻辑：在后续 ERP 迭代中，前端图片直传 R2 前加入 WebP 压缩，打破 2MB 的低效限制，为存放高清图做准备。
  2. 冻结独立站电商逻辑：现阶段停止开发独立站的 Order 和 Payment 模型，独立站只做静态展示引流和博客 SEO。
  3. 构思锁单机制：在设计 Etsy 联动的 API 时，提前预留 lock（锁单）和 unlock 状态，为未来独立站接入扫清障碍。