路线图
本页描述 ng-mfe 的发展现状与方向。Roadmap 为方向性描述,不构成任何发布承诺;分级依据是仓库内可复核的测试与 CI 证据,无法确认的一律如实描述、不评级。
阅读约定:
- "已实现并有测试佐证"每条都给出可复核的测试/CI 证据;
- "实验性 / 已知局限"是当前版本真实存在的问题,不回避;
- "规划中"来自审计建议,是提案而非排期;
- 想验证任何一条描述,按 工程实践总览 的命令在本地复现即可。
已实现并有测试佐证
以下能力在当前版本可用,且有对应测试/CI 证据支撑:
| 能力 | 佐证 |
|---|---|
| 微前端核心引擎(加载 / 生命周期 / 注册 / 健康检查) | packages 单测约 1617 用例;集成 lifecycle.spec、example-sub-app-lifecycle.spec |
| Proxy / Snapshot 双模式沙箱 + 三类 patch + CSS 三模式隔离 | 单测(css-isolation.spec 等)+ 集成 sandbox-integration.spec |
| 跨应用通信(EventBus / SharedState / RPC)与保护键 | 集成 cross-app-communication.spec;E2E cross-app-and-acl.spec |
| Angular / Vue / React 适配器与 Web Component、纯 JS 子应用形态 | 集成 adapter-bridges.spec;E2E 18 spec / 109 用例 |
| 多级缓存 L1/L2/L3、Read/Write-Through、getOrSet 单飞、LRU | cache-multilevel.spec、cache-service.spec |
| HTTP 管道 run() 回路、指数退避重试、Deduplicate | 契约测试 pipeline-contract.spec(Mock 短路/Cache 命中/领导跟随/Timeout/_noRetry) |
| Auth 单飞 refreshToken、ACL、TokenStore | auth-single-flight.spec、auth-acl-integration.spec |
| MapFactory(瓦片缓冲/prewarm)与 MapLayerRegistry(ACL 过滤) | packages 内地图相关单测 |
| Zoneless 纪律(禁 zone.js、provideZonelessChangeDetection) | guard:zoneless 脚本 + CI zoneless-guard job |
| 体积预算门禁(size-limit 9 条上限) | .size-limit.json + CI size-check job |
| 内存回收与页面稳定性 | E2E memory-leak.spec、lifecycle-stability.spec、page-refresh 等 |
| 部署构建与产物验收 | tools/deploy-build.ts;CI e2e.yml(deploy 模式全量 E2E) |
| 发布流水线(混淆 + 产物校验 + npm 发布) | .github/workflows/release.yml |
以上佐证可自行复核:npm run test 与 npm run e2e --list 看用例数;.github/workflows/ci.yml 与 e2e.yml 看门禁;各 spec 文件路径直接在仓库内检索。
实验性 / 已知局限
以下问题来自源码审计,当前版本如实存在(编号沿用审计报告):
- CLI 命令不可用:bin 入口
create-mfe-app.mjs缺失,脚手架命令无法执行;generateTemplate库函数仍可用; - Auth 401 无 refresh-and-retry(P12/B09):收到 401 的处理是直接登出,没有"刷新 Token 后重放原请求";
- deploy-build 字符串回填(P23):portal 产物 JS 靠字符串替换回填子应用 hash 文件名,构建输出变化时会静默失效(机制与局限详见 生产部署);
- ProxySandbox 白名单读透传(P24):白名单全局的读取直接走 rawWindow,隔离不完整;requestAnimationFrame 等未纳入追踪;
__MFE_GLOBAL_EVENT__镜像无消费者:全局事件镜像机制存在但无使用方;- correlationId 嵌入业务 payload:请求关联 ID 进入业务数据结构;
- CacheService
get使用 structuredClone:每次读取深拷贝,大对象有开销; - core
VERSION = '0.1.0'与包版本 0.2.0 不一致(packages/core/src/portal-application.ts); - 包 exports 指向 src 源码:依赖
tools/prepublish.ts在发布时切换,发布链路被绕过时会出错产物。
以上问题的共同点是不影响核心链路的正确性,但影响工程可靠性(CLI 不可用、发布链路脆弱、运行时版本号不准等);接入评估时应结合 安全实践 的遗留清单一起看。
规划中(Proposal)
以下为来自审计建议的方向性提案,非承诺、无时间表;每条附动机与初步思路,落地前会在仓库 issue 中公开讨论:
- Auth refresh-and-retry 动机:现状 401 直接登出,长会话用户体验差(P12/B09)。 思路:管道内识别 401 → 单飞
refreshToken()→ 重放原请求 → 仍失败才登出;需明确重放次数上限与幂等边界。 - 部署 manifest 化 动机:entry-map.json + JS 字符串回填机制脆弱(P23),构建输出变化即静默失效。 思路:构建期生成声明式 manifest 描述子应用入口,portal 运行时读取 manifest 而非把入口写死在产物字符串里。
- 沙箱隔离分级(none / soft / isolated) 动机:不同子应用信任度不同,一刀切的 Proxy/Snapshot 无法表达"完全不可信"(P24 等边界问题)。 思路:三档可选;高隔离档探索 iframe 等更强边界,低档换取兼容与性能。
- EventBus 协议显式化 动机:裸字符串事件名与无约束 payload 在多团队协作时易出错。 思路:事件名与 payload 的显式契约(类型/校验),保留向后兼容的宽松模式。
- SharedState 受控 Store 动机:子应用直接写全局状态难以审计;protectedKeys 之外缺少约束。 思路:可选的类 Store 受控读写层(actions/校验),渐进启用。
- 安全加固(与 安全实践 的"建议"项对应):CSP 头、SRI、统一输入消毒层的接入指引或框架支持。
版本策略
- 遵循语义化版本(CHANGELOG 明示);版本号由
tools/version-sync.ts在发布时统一同步到各包; - 重要变更记录于根
CHANGELOG.md,格式基于 Keep a Changelog; - 0.x 阶段 minor 版本亦可能包含破坏性变更(如 0.2.0 的 24 包收敛为 5 包),升级前请阅读对应版本条目。
版本历史
来自 CHANGELOG:
- 0.1.0(2026-05-17):初版。核心引擎、双模式沙箱、EventBus/SharedState、三框架适配器、企业级服务(ACL/Auth/Cache/Mock/Theme 等)、HTTP 管道、Schema Form/Chart/Smart Table/Map、CLI 工具、DevTools、完整示例(Portal + 5 子应用)、1722 单测 + 105 E2E、部署构建工具与 GitHub Actions CI/CD。
- 0.2.0(2026-09-09):24 个 npm 包收敛为 5 个发布包(core/services/adapters/ui/testing,全部子路径导出);缓存升级多级 L1/L2/L3(Read/Write-Through、CacheMonitor、getOrSet 单飞);HTTP 管道统一
run()回路与指数退避重试;refreshToken()单飞;MapFactory 与 MapLayerRegistry;VitePress 文档站。
如何贡献
- 阅读 贡献指南 了解分支、提交与评审约定;
- 从上方"实验性 / 已知局限"或 Proposal 中认领议题,先开 issue 讨论;
- 改动需通过 CI 六个 job(lint / test / build / typecheck / size-check / zoneless-guard)与 deploy 模式 E2E;
- 测试怎么写见 测试体系,体积红线见 性能实践。
认领建议:
- 修"已知局限"类问题(如 VERSION 不一致、entry-map 校验)通常范围小、验证明确,适合首次贡献;
- Proposal 类(refresh-and-retry、manifest 化)影响面大,必须先出设计讨论再动手;
- 与安全相关的改动请同步更新 安全实践 的"已实现/建议"分类,避免文档与能力脱节。