三个真实约束，决定技术栈
做一套面向花卉行业的交易平台，技术选型不能只看"流行什么"。这类项目有三个绕不开的约束：
- 要能私有化部署。花卉批发商与产地供应商往往希望数据落在自己服务器，甚至是配置不高的云主机或虚拟主机上；
- 要能二次开发。软件卖出去之后，客户会提"加个字段""改个流程"，交付方必须能在没有大型工程团队的情况下接手；
- 要多端共用一套业务代码。同一套商品、库存、订单、结算逻辑，要同时支撑小程序、APP、Web 与后台。
把这三条摆在前面，结论就比较清楚了：ThinkPHP 8 + MySQL 8。
为什么是 PHP
PHP 在这个场景里有几项很难被替代的优势：
- 部署门槛低。开启 PHP-FPM + Nginx/Apache 即可运行，共享型主机也能跑起来，不需要容器编排；
- 人力市场大。二三线城市的开发与运维都能接手，客户后续自研不会被技术栈卡住；
- 成熟稳定。ThinkPHP 8 是一套"约定优于配置"的框架，路由、ORM、中间件、命令行工具齐全，适合把业务分层写清楚。
我们在这套系统里把后端严格分成五条路由入口：B2B2C 采购端、O2O 同城端、商户端、员工端、平台后台。它们共用同一份 Model 与 Service，只在控制器层做请求形态适配，避免"每个端一套代码"的维护灾难。
为什么是 MySQL 8
交易系统的核心是账要算得对。MySQL 8 带来的三件事直接服务于这一点：
- 事务与行锁：库存扣减、额度占用、账单核销都必须在一个事务里完成，
SELECT ... FOR UPDATE与原子UPDATE是最后一道防线； - 窗口函数与 CTE：日报、榜单、账龄这类聚合查询，不必再写一堆临时表；
- UTF-8MB4：商品名、花材名里的生僻字与 emoji 不会丢字符。
配套的口径是：金额一律 DECIMAL(12,2)，不使用浮点；时间字段按域约定（供应链与订单域用秒级时间戳，财务与系统域用 DATETIME），不做"全局统一"这种看起来整齐、实际破坏语义的事。
一套代码，两种业务形态
平台上同时跑着两类业务，共用账号体系但数据隔离：
- B2B2C 供应链：产地供应商 → 平台仓/直发 → 下游花店，涉及阶梯价、加价规则、运费模板、质检、打包、发货、应付结算；
- O2O 同城：门店 → 本地消费者，涉及门店配送范围、即时配送、自提与预约。
两者通过统一的 users 账号域打通：一个手机号一个账号，消费者、供应商、花店老板、供应商员工、门店店员都是同一个账号的不同身份，身份档案各自独立。这样 C 端流量与 B 端生意不会互相污染，也不会出现"两个账号体系对不上账"的问题。
这套选型放弃了什么
诚实地讲，也放弃了三件事：
- 没有微服务。单体应用 + 清晰的域边界（users / sys / cms / crm / bbc / oo / active / fin / ana / pay 十个域）比一开始就拆服务更适合这个规模的客户；
- 没有引入 Redis 作为强依赖。缓存是可选加速层，去掉缓存系统仍能正确运行，这对私有化部署很关键；
- 没有做前后端同构。后台用 Vue3 单独构建，静态资源独立发布，运维只需要托管一份
dist。
后续的研发记录会围绕这套底座展开：数据库基线怎么划、定价与运费怎么算、权限怎么收口、多租户怎么改造。想先看能力清单，可以前往系统介绍。