应用交付与模板
很多“为什么导入后不对”“为什么别人不能继续改”“为什么发布后和创作区不一样”这类问题，本质上都属于应用交付边界没先想清楚。这页把模板、发布、协作、复制这些高频问题整理成 FAQ。
应用发布后，为什么和创作区不是实时同步的？
因为发布后的应用本质上是发布瞬间的快照。
这意味着：
- 创作区后来改了图表、过滤器、设置
- 应用集市里的已发布版本不会自动跟着变
- 需要手动执行重新发布，发布区才会更新
所以如果你看到“创作区已经改好了，但用户看到的还是旧内容”，先不要怀疑缓存，先确认是不是根本还没重新发布。
为什么导出的模板从 A 环境导入到 B 环境后，打开图表提示“数据包不存在”？
高频原因是：两边环境的数据包 ID 对不上。
数据包在不同环境里的 ID 通常是自增生成的，并不会天然保持一致。所以即使你在 B 环境导入了模板并替换了数据连接，图表里仍可能引用着原先环境的数据包 ID。
这类问题的处理重点不是重做模板，而是：
- 在 B 环境中手动替换数据包
- 确认模板里依赖的数据包已经重新绑定到当前环境可用的数据包
模板适合解决什么，不适合解决什么？
模板更适合解决：
- 平台方给租户或企业内用户下发标准分析样板
- 业务团队重复搭建同类看板时快速复用结构
- 报表应用需要统一版式、统一复杂报表模板
模板不适合解决：
- 不同环境结构差异很大、表结构并不一致
- 期待“一导入就完全零配置可用”
- 需要把跨环境的数据包 ID、权限、连接全部自动适配
如果目标环境的数据结构不一致，模板只能帮你复用骨架，不能替你消除所有迁移差异。
模板市场里的模板会把原始数据一起带出去吗？
不会按“原始线上数据直接带走”的方式处理。
模板上架时，使用的数据集会自动转为 Excel 文件数据集 作为样例数据展示。因此在决定把应用做成模板前，应先确认模板里的样例数据是否适合公开给模板使用者查看。
应该用“协作”、还是“创建副本”、还是“导出模板”？
先按目标判断：
| 诉求 | 更适合 |
|---|---|
| 多人一起继续编辑同一个应用 | 协作 |
| 别人基于当前应用另起一份自己改，不影响原应用 | 创建副本 |
| 跨环境、跨团队复用一个应用骨架 | 导出模板 / 使用模板新建应用 |
如果你真正想要的是“给别人一个可独立演化的新版本”，不要直接协作给他。
为什么被协作者能改应用内容，却不能发布或再协作给别人？
这是应用协作的默认边界：
- 被协作者在应用内部拥有接近 owner 的编辑能力
- 但不能发布、删除应用，也不能把该应用再次协作出去
这套限制是为了避免“内部共同编辑”和“正式对外交付”被混成同一层权限。
什么时候应该优先用 app hash，而不是 app id？
当发布后的应用还会被用于：
- 嵌入分析
- 页面跳转
- 自定义 JS
- 外部系统保存应用链接
这时更适合优先用 app hash。
因为重新发布时 app id 会变，但 app hash 保持不变。如果你把外部集成硬绑在 app id 上，重新发布后就容易失效。
跨应用复制图表时，最容易漏掉什么？
最容易漏的是：目标仪表盘的 layout 组织必须自己补完整。
跨应用图表复制不仅要知道源图表的 id 和 sourceAppId，还要把目标仪表盘当前的 layouts 组织好，并补上复制接口所需的 layout 信息。
所以这类问题通常不是“接口没提供能力”，而是“调用方没有把目标 dashboard 的布局状态准备完整”。
报表应用导入模板后，为什么还是要重新拖字段和配筛选？
因为模板解决的是版式和结构复用，不是自动完成所有业务数据映射。
对复杂报表来说，导入模板后往往还需要：
- 把业务字段拖到模板指定单元格
- 补条件筛选区
- 重新预览和发布
如果你把“导入模板”理解成“一键完整生成报表”，就会对它的实际边界产生误解。
进一步阅读：