外观
2026-08-23 Morpho Vault V2：风险模型、市场隔离与可信执行
- 数据时间：2026-08-23 Asia/Shanghai
- 研究对象：Etherealm Research Morpho Vault V2 Manager、内部风险模型、Accountable 风险证明与 owner-exit
- 报告类型：DeFi 技术架构 / Vault V2 策略与风控模型
- 资料来源：Morpho Vault Manager 策略蓝图、风险配置与 replay 场景、Vault V2 代码设计、生产控制面架构方案
核心判断
Etherealm Research 的 Morpho Vault 策略采用“约束先于收益”的顺序：先用资产透明度、市场规模、利用率、可撤流动性、集中度和相关风险预算限定可配置空间，再由 optimizer 在剩余空间内寻找借贷利率与激励收益。
Vault V2 保留这套 risk 设计，并把执行边界进一步收紧。全新 V2 vault 通过 MorphoMarketV1AdapterV2 管理 Morpho Blue Market V1 allocation；固定区块 snapshot 同时读取 adapter、market 和三层 cap；风险退出形成明确的 market isolation；发送前模拟原生 multicall，确认后复读仓位、idle、liquidity route 与 cap 不变量。独立 owner-exit 处理持有人退出，主 manager 只负责 vault 内部 allocation。
策略定位
Vault 管理器不接管 LP 本金，也不把资产转入管理人账户。管理权限集中在 curator、allocator、sentinel 等 V2 角色允许的配置与分配动作内。策略以真实资产为本金，收益来自公开借贷市场和可解释激励，风险规则先裁剪仓位，optimizer 随后处理资金配置。
| 层级 | 目标 | 执行含义 |
|---|---|---|
| 本金边界 | 以 USDC、USDT、WETH 等真实资产为本金 | 排除循环贷、黑箱抵押和项目方凭证代币的无限再质押路径 |
| 风险边界 | 先证明透明、可审计和具备退出路径 | 市场规模、流动性、利用率、单市场占比和相关风险预算均需通过规则 |
| 执行边界 | optimizer 只在 risk 裁剪后的空间内配置资金 | APY 无权越过 cap、deposit lock、strategy group、withdrawability 和外部风险 directive |
收益来源与风险处理
策略蓝图将 USDC vault 的目标定义为跑赢链上稳定币基准，将 WETH vault 的目标定义为跑赢主流 LST 回报。这些目标用于比较资金效率，不构成固定收益承诺。
| 收益来源 | 解释 | 风控处理 |
|---|---|---|
| 借贷利息 | Vault 把资产供给到 Morpho markets，向借款方收取利息 | 利率与利用率、市场规模、抵押品和即时可撤流动性一起评估 |
| 激励补贴 | 市场用代币激励吸引流动性 | 激励不能单独构成准入理由，统一折回风险调整后收益 |
| 稳健停车场 | wstETH/USDC、cbBTC/USDC、Sky sUSDS 类透明度较高的路径承担防守角色 | 承接 Degen 资金回转、赎回缓冲和风险升温时的降配资金 |
| Degen alpha | 早期市场、波动窗口、激励错配和短期利差 | 由单市场 cap、策略组预算、deposit lock 和流动性约束限制尾部风险 |
从 MetaMorpho V1 到原生 Vault V2
原有风险模型的政策层可以复用，协议执行语义需要重新建模。V1 依赖 supply queue、withdraw queue 和 reallocate；V2 围绕 adapter、cap ledger、liquidity route 和原生 multicall 运转。
| 维度 | MetaMorpho V1 设计 | Vault V2 改进 | 风险意义 |
|---|---|---|---|
| Vault 来源 | 管理既有 V1 vault 与 market queue | 面向全新部署的 V2 vault，无 shares/assets 迁移 | 避免把 V1 状态、角色和退出假设带入新系统 |
| 底层 allocation | Vault 直接维护 market allocation | 通过已安装的 MorphoMarketV1AdapterV2 接入 Market V1 | adapter identity 成为显式信任边界 |
| 新资金入口 | supply queue 顺序 | optimizer target 加 deposit lock 和三层 cap | 风险市场可保留现有头寸，同时禁止继续增仓 |
| 退出入口 | withdraw queue 顺序 | liquidity adapter 与 liquidityMarketIds 候选 | 退出路由从隐含队列位置变成显式可验证状态 |
| 上限 | 配置级 market cap 与组合约束 | adapter、collateral、market 三层链上 cap ledger | 计划同时服从协议 cap、共享 collateral cap 和单 market cap |
| 调仓 payload | V1 reallocate | V2 原生 multicall，先 deallocate、后 allocate | 提款先释放资金，存入不会暂时突破 cap |
| 状态读取 | vault、position、queue 等多项读取 | 同一固定区块读取 vault、adapter、market 与 cap | 降低跨区块状态拼接造成的错误计划 |
| 可撤性 | maxWithdraw / maxRedeem 与 queue 共同决定 | 两个方法可能固定返回 0，改读 shares、资产换算与 market liquidity | 将 V2 的 0 返回值视为协议条件，不误判为零资产 |
| 风险退出 | 风控收紧 target，再走 reallocate | smooth / battle market isolation，随后重新优化 | 出险 market 只减不增，释放资金按正常风险政策再分配 |
| 持有人退出 | 与 vault 常规赎回语义联系较紧 | 独立 owner-exit 进程和 rescue executor | allocator 风险处置与 owner 资产退出分权限、分 signer、分故障域 |
| 执行验收 | 交易发送与通知 | 同一 calldata 模拟、receipt、固定区块复读和不变量验证 | 发送成功不再等同于风险处置完成 |
V2 系统分层
| 模块 | 职责 | 对风控的意义 |
|---|---|---|
vaultV2Fetcher | 在固定区块读取 vault、Market V1 adapter、market 状态和三层 cap | 所有约束来自同一链上状态切片 |
riskAdapter | 应用市场准入、利用率、流动性、静态 cap 和策略组规则 | 给出 target、max supply、deposit lock 与退出原因 |
ExternalRiskEngine | 接入 Accountable 等 market-scoped 外部风险 provider | 将链下偿付、透明度和新鲜度证据收敛为统一 directive |
vaultV2Rescue | 把风险退出意图转换成 smooth 或 battle 隔离基线 | 退出量受真实 withdrawable liquidity 约束 |
optimizer | 在风险基线、cap 和 idle reserve 内重新配置资金 | 释放资金进入其他合格 market，缺少目标时保留 idle |
vaultV2Execution | 生成原生 multicall、模拟并复核执行后状态 | risk 退出可越过收益门槛，仍需经过执行安全门槛 |
vaultV2Runner | 编排 risk check、rebalance、通知、backoff 与确认 | 风险检查和常规收益优化拥有不同触发节奏 |
owner-exit | 独立监听 market 流动性并处理 share owner 退出 | 主 manager 不持有 owner-exit 权限，也不自动启动该服务 |
内部 risk 设计
市场准入
市场准入先按规模与透明度分层。下表保留原 USDC 策略参数快照，用于说明 risk policy；实际阈值应随 vault 资产、链、抵押品和市场深度单独配置。
| 规则 | 原策略参数示例 | 风控结果 | V2 语义 |
|---|---|---|---|
fullWhitelistMinSize | 20,000,000 | 达到完整白名单规模后按常规 cap 参与 | 仍需通过三层链上 cap 与 adapter 检查 |
partialWhitelistMinSize | 10,000,000 | 介于 full 与 partial 门槛之间时只允许受限暴露 | max supply 收紧，并进入组合占比约束 |
| 低于 partial 门槛 | blocked | 目标仓位降为 0并锁定新增 | 进入 market isolation，不进入新 allocation |
whitelist: true | 核心透明市场 | 可跳过部分通用筛选，但仍受静态 cap | 外部 EXIT 可以覆盖 whitelist |
excludeFromSupplyQueue | V1 市场级开关 | 保留退出路径，停止接收新存款 | V2 没有 supply queue，由 deposit lock 与 max supply 表达同一风险意图 |
full、partial、blocked 和禁止新增构成四层准入状态。V2 的改进是把“不能继续存入”从 queue 操作提升为 optimizer 约束：即使 market 仍在 adapter 中，计划也无法向它增加 allocation。
准入之后还要叠加 perMarketShareLimitPercent、partialPortfolioSharePercent、maxAllocation 和 allocationDriftTolerance。前两项控制相对组合占比，maxAllocation 给出绝对金额上限；自然利息只在 drift tolerance 内允许冻结在当前值，期间禁止加仓，超过容忍值后必须降回 cap。
利用率与可撤性
利用率风险来自供给被借款占用后的退出不确定性。原有模型同时看利用率阈值、目标利用率、即时流动性覆盖、每轮撤出比例和 dust 清零条件。
| 参数 | 原策略参数示例 | 含义 | V2 改进 |
|---|---|---|---|
utilizationExit | 0.96 | 高于阈值触发退出或降配 | 与内部 risk note、外部 EXIT 共同形成 isolation request |
utilizationTarget | 0.92 | 计算希望恢复到的目标利用率 | optimizer 在救援基线之上重新计算其余 market allocation |
liquidityCoveragePercent | 80 | 要求可用流动性覆盖头寸的显著比例 | V2 同时检查 market liquidity 与指定 liquidity route |
utilizationLiquidityConstrainedWithdrawPercent | 95 | 流动性不足时只使用本轮可撤能力的一部分 | smooth 继续分轮退出，battle 使用本轮全部可撤流动性 |
utilizationExitDust | 10,000 USDC | 避免对不可完成的小额尾仓反复发交易 | minimumWithdrawalAssets 抑制无意义中间动作，能够完成退出时不留下 dust |
utilizationExitDustLiquidityCoveragePercent | 103 | dust 清零需要额外流动性冗余 | 执行后复读确认真实剩余仓位，不以计划值代替完成状态 |
这套规则允许退出跨越多个 iteration。每轮只报告实际可执行的 deallocation，剩余风险继续留在下一轮状态中。V2 进一步区分了 vault 内 market isolation 与 share owner 退出：前者调整 allocation，后者把资产送到 owner 指定的 receiver。
集中度与策略组预算
单 market cap 无法识别多个市场共享同一抵押品、发行人、wrapper 或流动性来源的尾部风险。strategyGroups 将这些表面独立、经济上相关的 market 放进共同预算。
| 组别 | 原策略上限示例 | 控制对象 | V2 处理 |
|---|---|---|---|
managed-wrapper | 20% 或 450,000 USDC | 管理型 wrapper 和结构复杂市场 | 组预算与 adapter/collateral/market cap 取更严格结果 |
volatile-collateral | 30% 或 600,000 USDC | 波动抵押品相关市场 | 超限时优先削减组内低收益或风险更高的 allocation |
reusd-complex | 65% 或 1,500,000 USDC | 同一稳定币复合风险 | 达到预算后锁定整组新增资金 |
snusd-complex | 35% 或 800,000 USDC | 同一稳定币复合风险 | 相关 market 不因地址不同而获得独立预算 |
alt-stables | 45% 或 900,000 USDC | 非核心稳定币篮子 | 组合风险与单 market 流动性同时生效 |
apollo-complex | 10% 或 150,000 USDC | 单一复杂策略族 | 低绝对 cap 限制早期或难解释暴露 |
V2 的三层 cap ledger 补充了策略组预算：adapter cap 管适配器总暴露，collateral cap 管共享抵押品暴露，market cap 管单一 Market V1。策略组属于管理人风险政策，三层 cap 属于链上执行约束；计划必须同时通过两套限制。
调仓阈值与风险优先级
收益优化需要抑制小额、频繁和 gas 不经济的交易。原 V1 USDC 参数快照采用分段最小收益改善：
| 当前 APY 区间 | 原 V1 最小收益改善 | V2 配置示例 | 处理方式 |
|---|---|---|---|
0%+ | 15 bps | 10 bps | 普通 allocation move 需同时通过收益与 gas 门槛 |
10%+ | 20 bps | 20 bps | 高收益区间提高换仓要求 |
15%+ | 30 bps | 30 bps | 抑制追逐短期 APY 尖峰 |
原 V1 USDC 配置快照还使用 maxGasUsd = 5、supplyQueueMinScoreDelta = 20 和 minReallocateDelta = 1,000 USDC 限制无效调仓。V2 保留 minApyGain、maxGasUsd 与 minReallocateDelta，删除 supply queue 的执行语义。risk-enforced isolation 可以越过 APY 与 gas 收益判断，仍需通过同一 calldata 模拟、signer lease、receipt 和执行后验证。
外部风险与 Accountable 证明
内部 risk 主要读取链上市场事实。aHYPER 一类资产还需要链下储备、供应量、净资产与抵押率证据，因此 V2 增加 market-scoped ExternalRiskEngine。每个 provider 显式绑定 appliesToMarketIds，多个 provider 覆盖同一 market 时取更严格 directive；provider 失败只冻结其绑定 market 的新增暴露。
| Directive | 约束 | allocation 结果 |
|---|---|---|
ALLOW | 没有额外外部限制 | 继续服从内部 risk、策略组与三层 cap |
NO_INCREASE | max supply 钉在当前 allocation | 允许保持或减少，禁止继续增加 |
EXIT | deposit lock，目标暴露压到 0 | 进入 smooth 或 battle isolation，释放资金重新优化或保留 idle |
Accountable provider 在解析 JSON 前校验原始响应体 content-digest。经济新鲜度只使用 data.ts，并检查时间倒退、未来偏移、reserves、supply、net 与 collateralization 一致性；HTTP date、x-ts、Merkle 时间和 Nitro 内层时间仅作为辅助观测。
响应中的 signature-input 和 signature 只有在官方公钥、算法与验证流程明确后才具备密码学证明含义。缺少这些条件时，系统记录 present-unverified，内容摘要验证与签名验证保持分离。
偿付缺口、快速恶化或持续陈旧可以触发 EXIT。EXIT latch 持久化并跨重启保留，健康数据不会自动清除；操作者发起 clearance 时，provider 重新读取健康证明并核对目标 id，避免一次短暂恢复直接重开风险暴露。
市场隔离与 owner-exit
| 路径 | 权限和目标 | 退出量 | 安全边界 |
|---|---|---|---|
| Manager market isolation | allocator / sentinel；降低 vault 对出险 market 的 allocation | smooth 按配置比例分轮撤出；battle 使用本轮全部可撤流动性 | 只调用正常 deallocate，资金重新进入 optimizer；主路径不调用 owner withdraw/redeem |
| 独立 owner-exit | share owner 或预授权 rescue executor；把资产发送给 receiver | 按 owner shares、资产换算、V2 idle 与 Market V1 流动性取可执行值 | 独立 signer、触发模式、执行锁和通知；主 manager 不导入该服务 |
V2 的 maxWithdraw / maxRedeem 可以固定返回 0。owner-exit 因此从 balanceOf(owner) 与 convertToAssets 得到 owner assets，再用 market supply - borrow 和 idle 资产限定本轮退出量。三种触发模式分别服务不同需求：
liquidity：达到最低可执行流动性即可退出。risk-proof：ExternalRiskEngine 必须给出EXIT，同时满足最低流动性。either：流动性窗口可以触发，风险EXIT也会被完整记录和执行。
批量 rescue executor 要求每个 share owner 预先注册 receiver，并授权 executor 使用 vault shares。每个请求单独捕获外部 vault/adapter 调用失败，单一请求失败不会阻断后续 owner。正常 partial withdraw 不调用 forceDeallocate；该方法保留为 owner 最后手段，并伴随 share burn penalty。
所有发送路径按 chainId + signer 获取 execution lease。锁覆盖 nonce 复读、签名、发送、replacement、receipt 与 bundle 生命周期，防止 manager、owner-exit 或另一进程同时消费同一 signer nonce。异常退出留下的锁需要结合链上 receipt 与 nonce 人工处理。
V2 执行闭环
text
固定区块 snapshot
-> 内部 riskAdapter
-> ExternalRiskEngine
-> smooth / battle isolation baseline
-> optimizer 重新分配
-> 三层 cap 与 liquidity route 规划
-> 构造同一组 V2 multicall
-> authorized account 模拟
-> signer execution lease
-> 发送并等待 receipt
-> 新固定区块复读
-> target、idle、liquidity route 与 cap 不变量验证| 环节 | 风险检查 | 拒绝条件 |
|---|---|---|
| Snapshot | vault asset、adapter identity、IRM、market identity、cap state 来自同一 block | 身份不匹配、cap 缺失或 chain id 错误 |
| Plan | deallocate 排在 allocate 前；保留 idleReserveAssets | 无 market 满足最低退出流动性或计划超 cap |
| Simulate | 从真实授权账户模拟准备发送的同一 calldata | 任一调用 revert |
| Execute | 显式 chain 配置、RPC 策略和 signer lease | chain mismatch、lease 冲突或发送失败 |
| Confirm | 等待成功 receipt | revert、替换失败或确认超时 |
| Verify | 复核 market target、idle、liquidity route 与 cap | 无法由资产增长或舍入解释的状态漂移 |
source block 与 confirmation block 之间可能产生正常利息。market target 比较只吸收该区间内正向 vault-wide 实际资产增长；idle 仍只接受显式设置的最小单位舍入误差。adapter identity、cap allocation 和 liquidity route 保持精确检查。
Replay 与验证方法
原有离线 replay 固定市场规模、利用率、流动性、头寸、queue 和 cap，验证风险规则能稳定改变 target 与 payload。V2 复用同一风险政策，并把验收范围扩展到 adapter、cap ledger、liquidity route、原生 multicall 和执行后状态。
| Replay 场景 | 原风险意图 | V1 观察 | V2 改进分析 |
|---|---|---|---|
blocked-whitelist-exit | 市场规模跌破准入门槛后退出 | targetSupply 降为 0，资金转向 safe market，queue 移除 blocked | deposit lock 阻止新增，isolation 受真实 deallocation 流动性和 cap 约束 |
liquidity-constrained-utilization | stressed market 利用率 97%，高于 95% exit 时分轮撤离 | 本轮只撤出可撤能力的 50%，示例仓位从 200 降到 185 | smooth/battle 明确本轮退出强度，复读确认真实剩余 allocation |
group-share-cap | 同组两个 market 合计超过 50% 组合上限 | 低收益 market 降到 0，高收益 market 保留，组进入 deposit lock | 组预算再与 adapter/collateral/market 三层 cap 叠加 |
group-max-allocation | 组绝对上限用满后停止新增 | idle 流向组外 market | V2 optimizer 只能选择 cap 完整、adapter 有效且未被外部风险锁定的目标 |
dust-min-reallocate | 小额退出不继续制造噪音交易 | 尾仓退出后资金保留 IDLE | minimumWithdrawalAssets、idle reserve 和 post-state verify 共同约束 dust |
Replay 验证规则的确定性，固定区块 fork 验证真实合约调用兼容性，shadow dry-run 验证目标部署状态与角色。三条验证线回答的问题不同，任何一条都无法单独替代生产验收。
风控输出的 V2 映射
| 风控信息 | V1 表达 | V2 表达 | 复盘问题 |
|---|---|---|---|
| 单市场裁剪 | riskSummary | risk notes、max supply、deposit lock | 为什么减仓或禁止新增 |
| 相关风险预算 | groupSummaries | group constraints 与 optimizer breakdown | 同一风险族占用了多少预算 |
| 流动性排序 | queuePlan | liquidity candidates、active liquidity market 与 switch threshold | 退出依赖哪个 market，为什么切换或不切换 |
| 链下风险 | 无统一接口 | ExternalRiskAssessment、directive、evidence digest 与 latch | 哪份证明改变了 market 约束 |
| 风险退出 | targetSupply / queue update | rescue mode、planned withdrawal、remaining withdrawal | 本轮实际隔离多少，剩余多少 |
| 执行动作 | V1 reallocate payload | V2 multicall operations 与 target supplies | 链上将执行哪些 deallocate/allocate |
| 完成验收 | 交易与通知 | receipt 加 post-state invariants | 交易确认后，风险状态是否真的按计划改变 |
生产控制面设计
V2 manager 涉及生产签名、链上监听、WebSocket/mempool、nonce、执行锁、风险 latch 和本地应急状态。部署采用 Cloudflare 入口与 Docker 可信执行面的混合拓扑：
text
Cloudflare Pages 静态 UI
-> Cloudflare Access
-> Cloudflare Tunnel
-> Docker control-api
-> PostgreSQL 权威库
-> manager-agent
-> projector
-> 独立 owner-exit
-> 本地 SQLite durable outbox| 组件 | 设计职责 | 风险边界 |
|---|---|---|
| Pages | 静态控制台 | 不持有 signer，不承担链上监听或执行 |
| Access | 分别保护 UI 与 API | origin 继续校验 Access token、issuer、audience 和 expiration |
| Tunnel | 由服务器建立出站连接暴露 control-api | API 与数据库不开放公网端口 |
| PostgreSQL | 配置版本、审批、命令、事件、投影和审计的唯一真相源 | API、manager、projector、migration 使用不同数据库角色 |
| SQLite | 开发测试与 manager 本地 durable outbox | 数据库故障时先持久化 execution intent；outbox 也失败则停止主路径发送 |
| Docker services | 隔离 control-api、manager-agent、projector 与 owner-exit | 按权限、生命周期和故障域拆分进程与网络 |
| D1 | 可选边缘只读投影 | 只从 PostgreSQL outbox 投影，不参与 API 双写 |
owner-exit 使用独立 profile、signer secret、数据库角色和 Access hostname。主 API 只接受高层命令；manager 重新检查命令类型、审批、有效期、配置版本、链上状态、risk、simulation 和 execution lease，不接收数据库中预制的任意 calldata。
策略边界
| 可管理风险 | 控制方式 | V2 增强 |
|---|---|---|
| 市场规模不足 | whitelist 分层和 blocked 退出 | deposit lock 加 market isolation |
| 利用率过高 | utilizationExit / utilizationTarget | smooth/battle 分轮退出与 post-state 复读 |
| 流动性不足 | coverage、withdraw capacity、dust 规则 | 显式 liquidity route 与 owner-exit 流动性触发 |
| 单市场集中 | per-market share 与 max allocation | market cap ledger |
| 相关市场叠加 | strategy group 预算 | collateral 与 adapter cap ledger |
| 链下偿付与透明度 | 人工观察或专项规则 | market-scoped ExternalRiskEngine、Accountable digest 和 EXIT latch |
| 无效调仓 | min APY、max gas、min delta | risk action 越过收益门槛，执行安全门槛保持不变 |
| 多进程签名冲突 | nonce 与发送重试 | chainId + signer execution lease |
| 剩余风险 | 原因 |
|---|---|
| 协议、adapter 或集成漏洞 | 风控只能覆盖已经纳入状态读取和执行不变量的路径 |
| 稳定币发行人、储备与法律权利 | 透明度和证明降低信息风险，无法消除发行人和资产索取权风险 |
| 极端流动性枯竭 | 分轮隔离提升可执行性，无法创造 market 中不存在的流动性 |
| 外部证明被攻破或停止更新 | digest、freshness 与 latch 降低风险，可信公钥和独立验证仍需完整设计 |
| RPC、mempool、MEV 与 gas 变化 | 多 RPC、私有发送、监听和 backoff 提升韧性，无法保证任意时点成交 |
| owner 与角色治理 | 独立服务和权限减少耦合，最终安全仍依赖角色配置、timelock、密钥和操作纪律 |
结论
Morpho Vault V2 将原有的市场准入、利用率、流动性、集中度、策略组预算和调仓阈值保留下来，并把它们落到更严格的链上执行模型中。V1 的 queue 约束被 deposit lock、liquidity route 和三层 cap ledger 替代；风险退出形成 smooth/battle isolation；链下偿付证据通过 ExternalRiskEngine 进入同一 market 约束；执行结果由固定区块复读和不变量验收确认。
这套设计追求可解释的收益、有限的风险预算和可验证的退出。每笔 allocation 都应能回到来源市场、风险政策和 cap；每次退出都应说明触发证据、本轮可撤量、剩余风险与执行后状态；每次生产操作都应留下配置版本、审批、simulation、lease、receipt 和 audit event。
来源
| 材料 | 使用范围 | 证据属性 |
|---|---|---|
| Morpho Vault Manager 策略蓝图 | 本金、收益来源、市场准入、利用率、集中度和策略组设计 | 策略设计材料 |
| 原 USDC 风险配置与 replay fixtures | 参数示例、blocked exit、受限流动性、group cap 与 dust 场景 | 配置快照与离线确定性场景 |
| Vault V2 planner、fetcher、execution、runner 与 rescue 设计 | adapter、cap ledger、liquidity route、multicall、isolation 与执行后验证 | 本地源码设计 |
| ExternalRiskEngine 与 Accountable provider 设计 | directive、digest、freshness、偿付一致性与 EXIT latch | 外部风险接口与实现设计 |
| owner-exit 与 rescue executor 设计 | V2 share owner 退出、流动性触发、execution lease 与权限隔离 | 独立应急路径设计 |
| 生产控制面架构方案 | Pages、Access、Tunnel、Docker、PostgreSQL、SQLite 与 D1 分工 | 生产部署设计 |