定位与设计
TransOne 的品牌定位、技术路线对比、能力边界与架构方向。
来源
本文是规划稿要点速览，权威依据见仓库内 docs/positioning.md 全文。一句话定位
一套 TypeScript 源码，通过编译期静态转换产出 Web 与多端小程序原生工程，未来扩展原生 App 的跨端前端框架。核心主张：一套源码，多端原生产物，零运行时桥接。
为什么是编译期静态转换
| 方案 | 代表 | 机制 | 代价 |
|---|---|---|---|
| 运行时桥接 | uni-app | 框架运行时 + 编译产物（自定义组件 + 运行时适配层） | 产物依赖框架运行时，包体大，调试隔层 |
| 编译转换 + 运行时适配 | Taro | Babel 编译 + 运行时 reconciler | 运行时依赖框架子集，性能与兼容性受限 |
| 编译期静态转换（本项目） | TSone build --mp-weixin 原型 | 静态分析 VNode 子集 → 目标端原生模板 / 组件代码 | 对源码形态有约束（必须可静态编译），需文档化限制 |
- 产物即原生工程：直接由各平台官方工具链构建、预览、发布，无框架运行时依赖。
- 体积与性能最优：小程序端尤其敏感，静态转换产物最接近手写原生。
- 代价可控：每端维护一个静态编译目标（模板语法、样式、API 映射），不可静态编译的写法在编译期快速报错。
能力边界
首期做（M1–M3）：Web 产物、微信 / 阿里 / 字节小程序静态转换、响应式与类组件、目标端抽象（Target）。
首期明确排除：SSR、devtools、HMR、JSX 编译器、运行时跨端桥接、App 端（列为远期并预留 Target 扩展点）、第三方运行时。
架构方向
每个端一个编译目标（Target），编译器按 Target 分发代码生成：web 直接渲染（与 TSone 一致）；mp-weixin 产出 WXML / WXSS / JS；mp-alipay 与 mp-bytedance 已实现；app-* 为远期占位。编译流水线：入口文档 → 静态分析（可编译性校验）→ VNode 子集抽取 → 各 Target 代码生成 → 原生工程文件输出。
设计约束
- OOP + 策略模式 + SOLID，对齐 TSone 项目内 OOP 设计约束。
- 新增渲染 / 编译行为优先扩展或拆分 Strategy。
- 零外部运行时依赖；Bun-first 工具链。
- TypeScript strict 风格，避免新增 any；公共 API 优先泛型、unknown、显式接口。