更新与版本
这一页说明组件发布之后怎么改、怎么发新版本，以及版本号什么时候必须动。
两条更新路径
| 路径 | 适合 | 能改什么 |
|---|---|---|
| 更新页（Web） | 首次发布之后的常规迭代 | 代码、预览配置、描述、标签 |
comphub upload | 只改代码、想跳过页面操作 | 只发布代码，不碰元信息 |
首次发布仍然只能走上传页，因为 __id__ 是那一步写入的。
用更新页
- 下载当前版本：在「我的组件」里找到组件，点击「更新」，先下载线上版本作为基线。
- 本地修改：在项目里改代码、补文档。
- 本地验证：用本地服务预览，确认原有功能没有回归。
- 提交更新：回到更新页，选择修改后的文件夹，抬高版本号，按需调整预览与描述，点击「更新」。
仅修改描述、标签或预览配置时，不需要抬版本号。
用 CLI 更新
bash
comphub login # 每台机器一次
cd src/components/MyComponent
comphub upload -m "修复 tooltip 定位"也可以显式指定目录：
bash
comphub upload src/components/MyComponent -m "修复 tooltip 定位"与更新页的区别：
- 必须抬版本号：本地
comp.json的version不大于线上时，CLI 直接拒绝。 - 不碰描述、标签、预览配置：这些只能走更新页。
提交前可以先干跑一次：
bash
comphub upload -m "修复 tooltip 定位" --dry-run--dry-run 会打印项目路径、组件 ID、线上版本与将要发布的版本，然后停止，不提交。
语义化版本
主版本.次版本.补丁版本| 类型 | 变更 | 示例 |
|---|---|---|
| 补丁 | 修 bug，向后兼容 | 1.0.0 → 1.0.1 |
| 次版本 | 新增功能，向后兼容 | 1.0.0 → 1.1.0 |
| 主版本 | 破坏性变更 | 1.0.0 → 2.0.0 |
必须升版本：改了组件代码、props 接口或行为逻辑。
可以不升：只改描述、标签、预览配置。
修改版本号的两种方式
更新页：在配置区直接改版本号输入框，平台会同步写入 comp.json。
本地手动改：
json
{
"name": "MyComponent",
"version": "1.1.0"
}改完记得保存，CLI 读取的就是这个文件。
多版本并存
平台保留历史版本。使用者可以：
- 在预览页切换版本查看差异。
- 下载任意历史版本。
- 在自己的项目里锁定使用的版本。
已下载的旧版本不会因为新版本发布而自动变化。
变更日志
建议在 README.md 里维护：
markdown
## 更新日志
### 1.1.0 (2026-10-26)
- 新增：支持自定义主题色
- 优化：大数据量下的渲染性能
### 1.0.1 (2026-10-20)
- 修复：某些情况下 tooltip 不显示使用方看 README 比看版本号更能判断要不要升级。
提交结果不确定时
如果 CLI 报 Submit result cannot be confirmed 或超时，服务端可能已经写入。不要直接重试，先到平台的组件详情页确认最新版本：
- 版本已更新：无需重试。
- 版本没变：再执行一次上传。