---
url: /v6.2/app-delivery-template-faq.md
---
# 应用交付与模板

很多“为什么导入后不对”“为什么别人不能继续改”“为什么发布后和创作区不一样”这类问题，本质上都属于**应用交付边界**没先想清楚。这页把模板、发布、协作、复制这些高频问题整理成 FAQ。

## 应用发布后，为什么和创作区不是实时同步的？

因为发布后的应用本质上是**发布瞬间的快照**。

这意味着：

* 创作区后来改了图表、过滤器、设置
* 应用集市里的已发布版本不会自动跟着变
* 需要手动执行**重新发布**，发布区才会更新

所以如果你看到“创作区已经改好了，但用户看到的还是旧内容”，先不要怀疑缓存，先确认是不是根本还没重新发布。

## 为什么导出的模板从 A 环境导入到 B 环境后，打开图表提示“数据包不存在”？

高频原因是：**两边环境的数据包 ID 对不上**。

数据包在不同环境里的 ID 通常是自增生成的，并不会天然保持一致。所以即使你在 B 环境导入了模板并替换了数据连接，图表里仍可能引用着原先环境的数据包 ID。

这类问题的处理重点不是重做模板，而是：

1. 在 B 环境中手动**替换数据包**
2. 确认模板里依赖的数据包已经重新绑定到当前环境可用的数据包

## 模板适合解决什么，不适合解决什么？

模板更适合解决：

* 平台方给租户或企业内用户下发标准分析样板
* 业务团队重复搭建同类看板时快速复用结构
* 报表应用需要统一版式、统一复杂报表模板

模板不适合解决：

* 不同环境结构差异很大、表结构并不一致
* 期待“一导入就完全零配置可用”
* 需要把跨环境的数据包 ID、权限、连接全部自动适配

如果目标环境的数据结构不一致，模板只能帮你复用骨架，不能替你消除所有迁移差异。

## 模板市场里的模板会把原始数据一起带出去吗？

不会按“原始线上数据直接带走”的方式处理。

模板上架时，使用的数据集会自动转为 **Excel 文件数据集** 作为样例数据展示。因此在决定把应用做成模板前，应先确认模板里的样例数据是否适合公开给模板使用者查看。

## 应该用“协作”、还是“创建副本”、还是“导出模板”？

先按目标判断：

|诉求|更适合|
|-|-|
|多人一起继续编辑同一个应用|协作|
|别人基于当前应用另起一份自己改，不影响原应用|创建副本|
|跨环境、跨团队复用一个应用骨架|导出模板 / 使用模板新建应用|

如果你真正想要的是“给别人一个可独立演化的新版本”，不要直接协作给他。

## 为什么被协作者能改应用内容，却不能发布或再协作给别人？

这是应用协作的默认边界：

* 被协作者在应用内部拥有接近 owner 的编辑能力
* 但不能发布、删除应用，也不能把该应用再次协作出去

这套限制是为了避免“内部共同编辑”和“正式对外交付”被混成同一层权限。

## 什么时候应该优先用 app hash，而不是 app id？

当发布后的应用还会被用于：

* 嵌入分析
* 页面跳转
* 自定义 JS
* 外部系统保存应用链接

这时更适合优先用 **app hash**。

因为重新发布时 **app id 会变，但 app hash 保持不变**。如果你把外部集成硬绑在 app id 上，重新发布后就容易失效。

## 跨应用复制图表时，最容易漏掉什么？

最容易漏的是：**目标仪表盘的 layout 组织必须自己补完整**。

跨应用图表复制不仅要知道源图表的 `id` 和 `sourceAppId`，还要把目标仪表盘当前的 `layouts` 组织好，并补上复制接口所需的 layout 信息。\
所以这类问题通常不是“接口没提供能力”，而是“调用方没有把目标 dashboard 的布局状态准备完整”。

## 报表应用导入模板后，为什么还是要重新拖字段和配筛选？

因为模板解决的是**版式和结构复用**，不是自动完成所有业务数据映射。

对复杂报表来说，导入模板后往往还需要：

* 把业务字段拖到模板指定单元格
* 补条件筛选区
* 重新预览和发布

如果你把“导入模板”理解成“一键完整生成报表”，就会对它的实际边界产生误解。

进一步阅读：

* [模板市场](template.md)
* [应用发布](app-publish.md)
* [应用协作](app-collaborate.md)
* [报表应用](report-app.md)