流、调度与工程化
L24 生态、稳定性与渐进落地
本课目标
- 知道 v4 的包结构与稳定性标记
- 能给出一条渐进引入路线
前置课时尚未完成：L15、L21
可以自行跳转学习，但按顺序推进会更省力；学情分析会把这类缺口归入「前置缺口」。
一个生态，零依赖
v4 把原先分散的平台、RPC、Cluster、CLI、AI、SQL、Workflow 等能力收进 effect 单包，核心包零运行时依赖；平台特定驱动／AI provider／OpenTelemetry 集成仍作为独立 @effect/* 包，但全生态统一版本号、同步发布。
导入路径与版本锁步
← 代码可左右滑动 →
npm install effect@4.1.4
# 需要 pg 驱动时：@effect/sql-pg@4.1.4（版本必须对齐）
import { Effect, Layer, Stream } from "effect"
import { Schema } from "effect/schema"
import { HttpRouter } from "effect/http"
import { Sql } from "effect/sql"💡 子路径模块带 @stability 标记：stable 严格遵循 semver；unstable 在 minor 可能有破坏性变更；experimental 在 patch 也可能变。选型时先看稳定性标签。
渐进落地路线
- 第 1 步：只把「错误最乱」的一个函数改成 Effect，边界处 runPromise。
- 第 2 步：把外部依赖抽成 Context.Service + Live/Test 两层配方。
- 第 3 步：给 I/O 加 retry / timeout / Scope，享受结构化中断。
- 第 4 步：在应用根部用 ManagedRuntime.make(MainLive) 统一装配一次。
⚠️ ManagedRuntime 的一个坑
它在首次使用时构建 Layer 并缓存结果。若首次构建失败，这个失败会被一直保留，后续所有运行都失败且不重建。对可能瞬时失败的构造，应在 Layer 内部用 Effect.retry，而不是指望 runtime 自愈。
交互演练
关键术语
@stability
v4 模块的稳定性标记：stable / unstable / experimental
ManagedRuntime
从根 Layer 构建一次、可复用并负责释放资源的运行时
常见误区
× 把 unstable 模块直接用到长期维护的核心路径上而不做隔离。
× 在 React / Serverless 每个请求里重新构建一次根 Layer。
随堂测验（即时反馈，答题计入掌握度）
Q1v4 生态包的版本规则是？
Q2ManagedRuntime 首次构建失败会？