结论先说
这是一套体量不小的原生 PHP 项目，用一套后端同时撑起 H5 APP、PC 前台和 21 屏运营后台，没有引入任何框架或 Composer 依赖，数据库 21 张表把担保交易、悬赏托管、钱包提现和端到端加密私信全串了起来。
真正值得研究的不是页面数量，而是它把担保交易状态机和资金恒等式当成了系统底座：下单时固化费率快照，订单走完自动放款，钱包四个余额格子在任何时刻都守恒。
需要提前说明的是，这套系统面向的是”情报买卖”这个敏感品类，用 USDT 计价，文中会单独讲清楚合规问题。
项目构成
项目根目录分成三块，外加一份完整 Android 构建工具链。
| 部分 | 技术 | 规模 |
|---|---|---|
| 后端 | 原生 PHP 8+ | 8 个内核类 + 18 个控制器 |
| 数据库 | MySQL 5.7+ | 主表 21 张 + 扩展表 11 张 |
| H5 APP | 原生 JS + CSS | 15 屏 |
| 运营后台 | 原生 JS + CSS | 21 屏 |
| PC 前台 | 响应式原生 JS | 自适应门户 |
| 移动壳 | Capacitor 7 | Android / iOS |
| 桌面端 | Electron | Windows / macOS |
打包体积 1.47GB，绝大部分是被塞进 .toolchain 的 Android SDK：aapt2、d8、lld、clang 一整套，还有 JDK。刨掉工具链，项目本体其实不大。
内核设计
core/ 目录只有 8 个文件，但把该有的都覆盖了，全程不依赖框架。
| 文件 | 作用 |
|---|---|
DB.php |
PDO 单例，强制参数绑定 |
Router.php |
静态路由优先，支持参数路由 |
Request.php |
输入封装，类型安全取值 |
Response.php |
统一 JSON 输出 |
Auth.php |
Token 签发校验与审计 |
Biz.php |
加密、脱敏、金额计算 |
Validate.php |
入参校验与 HTML 清洗 |
Config.php / Env.php |
点号配置读取与环境变量 |
路由表在 api-router.php，控制器按业务域拆在 api/ 下，例如 IntelController 管情报、BountyController 管悬赏、OrderController 管验收与仲裁、WalletController 管钱包。
后台控制器单独一组，ManageController 有 66KB，装了 12 个运营扩展模块和 RBAC；AdminController 36KB 管 A1 到 A7 核心运营屏。
数据库结构
sql/ 目录里除了 schema 和种子数据，还有九个 extend-*.sql 增量脚本，全部写成幂等，可以重复执行。
主表按业务域分组：
- 用户域：
ie_user、ie_user_privacy、ie_kyc、ie_admin - 情报域：
ie_intel，字段含密级（S/A/B/公开）、机审评分、加密正文 - 悬赏域：
ie_bounty，含托管赏金、接单数、线索数、加注上限 - 交易域：
ie_order、ie_dispute - 资金域：
ie_wallet、ie_asset、ie_flow、ie_withdraw、ie_channel - 消息域：
ie_conversation、ie_message，只存元数据与密文 - 论坛域：
ie_forum、ie_thread - 治理域：
ie_audit_log、ie_rule_set、ie_locale、ie_stat_daily
担保交易状态机
订单流转一共五个状态，规则写得很清楚：
1 托管中 ──买家验收──→ 3 已放款
├──卖家交付──→ 2 待放款 ──超时 72 小时自动──→ 3 已放款
└──任一方申诉──→ 4 争议仲裁 ──裁决──→ 3 已放款 / 5 已驳回三条设计约束值得单独拎出来。
费率快照：下单那一刻把费率固化进订单，之后管理员改规则不会影响进行中的单子。做过分账系统的都知道，这一条能省掉大量对账纠纷。
金额恒等式：买家实付等于原价加平台服务费，卖家到账等于原价减平台服务费，两边永远对得上。
钱包恒等式：总资产等于可用加担保托管加悬赏托管加提现中，交易全程守恒。
超时自动放款靠定时任务，POST /api/cron/auto-release 每 10 分钟跑一次，用独立的 CRON_TOKEN 鉴权。
提现与风控
提现规则在 config/config.php 里可以调，默认值是这样：
| 项 | 值 |
|---|---|
| 手续费档位 | 0.10% / 0.30% / 0.60%，支付宝固定 0.60% |
| 单笔限额 | 50 – 50,000 USDT |
| 日限额 | 100,000 USDT，每天最多 3 笔 |
| 大额复核 | 单笔 ≥ 10,000 USDT 需双人双签 |
双人复核不只用在提现。大额放款要填第二复核人 ID，大额仲裁要法务同步审批，规则集变更要二次确认加审计留痕，风控处置全量写 ie_audit_log。
私信加密边界
IM 这块的设计思路比较特别，平台监管会话但看不到正文。
风控只命中元数据特征，比如消息数突增、时间跨度异常、关联订单、模型评分。要调阅正文必须走”申请加审批”两道流程，后台 KPI 明示”0 内容已解密”。留存策略分级，阅后即焚 1 小时或 24 小时，平台留存 90 天或 180 天。处置动作全程留痕并通知双方。
对应的接口是 POST /api/im/send 发加密消息，后台 POST /api/admin/decrypt-req 提交调阅申请。
安全实现
README 列了十条，我逐条核对了代码结构，基本都能对上。
| 项 | 做法 |
|---|---|
| SQL 注入 | 全 PDO 参数绑定，EMULATE_PREPARES=false |
| XSS | 输出侧 htmlspecialchars，富文本走白名单 |
| 密码 | sha256(salt + pwd + secret)，独立 salt 列 |
| Token | HMAC-SHA256 签名，带 exp 过期校验 |
| 越权 | 订单与会话详情校验买卖双方归属 |
| 角色隔离 | 用户 Token 与管理员 Token 互斥 |
| 目录穿越 | 静态服务用 realpath() 做前缀校验 |
| 敏感数据 | 证件号 AES-256 加密，IM 正文密文入库 |
| 审计 | 敏感操作写 ie_audit_log，含 IP 与操作者 |
| 幂等 | 已放款订单拒绝重复放款 |
部署要点
环境要求 PHP 8.0 以上，需要 pdo_mysql、mbstring、openssl、json 四个扩展，数据库 MySQL 5.7 以上用 InnoDB 加 utf8mb4。
初始化三步，先导入 schema.sql、seed.sql，再导 extend.sql 补后台扩展表，然后复制 .env.example 为 .env 填连接信息，最后跑 php install.php 生成密码 hash。
本地调试一条命令就够：
php -S 127.0.0.1:8911 -t public public/index.php四个入口分别是 /web/ PC 前台、/app 移动端、/admin 后台、/api/* 接口。文档根要指向 public 目录，.env 和 .git 必须在 Nginx 里显式禁掉。
上线前有两件事不能忘：替换 APP_TOKEN_SECRET，否则 Token 可以被伪造；替换后重新执行 php install.php 刷新密码 hash。
项目自带 e2e.php，覆盖 67 项 API 端到端验证，改完接口可以拿它回归。
需要认真对待的合规问题
这部分比技术细节更重要，我按看到的事实直说。
情报交易本身处于法律灰区。 系统里的”情报”没有内容边界，实际可能承载个人信息、商业机密甚至更敏感的数据。国内对个人信息买卖有明确刑事规定，平台方作为交易撮合者难以免责。
USDT 计价与提现是高风险组合。 全站以 USDT 计量，提现走加密货币通道，且预留了支付网关接口。这套结构容易被用于跨境资金转移，涉及外汇与反洗钱监管。
担保交易加悬赏模式容易被灰产利用。 匿名发布、托管放款、仲裁兜底，这套流程如果被用于数据买卖或代做任务，平台既是通道也是见证方。
端到端加密与监管留痕存在张力。 系统一边声称”平台不可解密”，一边保留了调阅审批流程和元数据风控。真运营起来，这个平衡点很难把握，法律上也未必站得住。
演示数据里含 96 条种子记录与多个演示账号，上线前应当清空，避免带着测试数据对外。
技术层面的建议：APP_TOKEN_SECRET 与 CRON_TOKEN 必须换成高强度随机串；.env、sql/、core/ 都要挡在公网外；支付网关回调必须验签且做重放保护；上线前用 e2e.php 全量回归一遍，再补充越权与金额篡改的负向测试。
适合谁研究
纯从工程角度看，这套代码有几个值得学的地方：不依赖框架怎么组织路由与控制器、担保交易状态机怎么设计得不容易出错、资金恒等式怎么在代码里落地校验、多端共用一套设计令牌怎么维护。
但如果你打算真拿它运营，请先把上面合规部分想清楚，并咨询专业法律意见。这类品类不是技术问题，是法律问题。
源码仅供学习研究与技术参考，请勿用于任何违法违规用途。因使用本源码产生的一切后果，由使用者自行承担。
评论(0)