企业官网建设流程全解析

1. 数据大屏的"身份证"：搞清楚ID到底是什么

DataEase的数据大屏，说到底就是一张保存了画布布局、组件配置、数据源绑定关系的一张"配置单"。而这张配置单在系统内部靠什么区分？靠的就是大屏ID。群里经常有人问"dataease数据大屏id 所在位置"，要么是二次开发需要拼URL，要么是想做iframe嵌入，要么是想通过接口动态切换大屏。不管哪种场景，第一步都是先把这个ID揪出来。

先说结论，DataEase里的大屏ID不是前端临时生成的随机串，它是后端数据库里大屏资源表的主键。这个ID在系统里贯穿始终：你打开大屏页面时，URL参数里有它；系统内部查询大屏配置时，SQL条件里有它；前端渲染组件时，请求接口的路径里也有它。所以只要找到ID，就等于拿到了操作这个大屏的钥匙。

但问题是，DataEase的界面设计得比较"干净"，正常使用状态下你根本看不到大屏ID。很多人在控制台里翻来翻去，最多只能看到大屏名称和缩略图。加上网上关于这个问题的回答零零散散，大多只给一个"看URL"的笼统结论，真正拿到手能用的信息很少。这篇就把所有找ID的路径和原理一次性说清楚。

2. 三层定位法：不写一行代码也能找到大屏ID

2.1 界面层：从浏览器URL里直接提取

这是最快、最零门槛的办法，适合任何使用者，不需要懂数据库也不需要对系统结构有了解。

操作方式很简单：进入DataEase系统，打开你要找ID的那个数据大屏，正常进入编辑或预览页面，然后看浏览器地址栏。

如果你用的是DataEase v1.x系列，大屏预览和编辑的URL大致长这样：

http://你的服务器地址:端口/#/panel/view/6e0e6e8a4d1b4f0e8f194d3d8e88dabc

末尾那串6e0e6e8a4d1b4f0e8f194d3d8e88dabc就是大屏ID。

如果用的是v2.x系列，路由结构会有些变化，大屏页面的URL大概是这样的格式：

http://你的服务器地址:端口/#/dashboard-view/2f8a6f0c7d4a49a9b38dcef6f197fd9c

同样，2f8a6f0c7d4a49a9b38dcef6f197fd9c这串就是ID。

这里要特别注意，URL里可能同时存在多个参数和路径段，别认错。我见过有人把端口号后边的#/panel也当成ID的一部分，复制出去怎么拼都不对。大屏ID永远是路径最后一段那个不带扩展名的32位字符串（v1.x）或类似格式的标识串（v2.x可能更长或不同规律），不是前面的路由名称。

2.2 数据库层：从大屏资源表里按名称反查

URL方式虽然快，但有两个致命的局限：第一，你必须已经能打开这个大屏；第二，如果大屏在系统里被频繁复制、导入导出，URL里的ID可能被系统重新生成了，跟你数据库里记录原始ID对不上。这个时候，数据库反查是最靠谱的办法。

DataEase的后端数据存储在MySQL中，大屏相关的表在v1.x里叫dashboard，v2.x里实际存储画布配置的表名可能不同（有的版本叫dashboard，有的版本把画布节点和基础信息拆开了），但核心思想一致：找一张记录大屏名称和ID映射关系的表。

连接数据库之后，执行下面这条SQL（以v1.x为例）：

SELECT id, name, create_time, update_time FROM dashboard WHERE name LIKE '%你的大屏名称%';

把你的大屏名称替换成真实名称，执行后就能返回这张大屏的ID。如果系统里存在同名大屏，注意用create_time或update_time来区分哪个是你真正要找的。

v2.x的用户先查一下有哪些表：

SHOW TABLES LIKE '%dashboard%';

看到表名后，先看一下表结构，通常有name或title这样的字段，再按名称过滤：

SELECT * FROM 找到的表名 WHERE name LIKE '%关键词%';

数据库层定位ID的好处是精准，而且能顺带看到这条大屏记录的创建时间、更新时间、创建人等元数据。对二次开发来说，这些信息往往比ID本身还有用——比如做数据统计、做权限控制、做自动清理，都需要从这张表里捞出全量大屏清单。

2.3 接口层：通过浏览器开发者工具抓取API请求

如果你既不想登录数据库，又觉得URL不够直观，还有一种比URL复杂一点点、但比数据库更“实时”的方法：浏览器开发者工具的Network面板。

操作过程是：进入大屏预览页，按F12打开开发者工具，切到Network（网络）标签页，刷新页面，在请求列表里筛选XHR或Fetch类型的请求，找到返回数据中包含大屏名称的接口。

DataEase的后端接口设计比较有规律，大屏详情相关的接口路径里通常直接带着ID，例如：

/api/dashboard/queryWithCanvas/2f8a6f0c7d4a49a9b38dcef6f197fd9c

只要看到这种路径格式，末尾处的ID就是大屏ID。在请求列表里点开该请求，看请求URL或者Preview里的返回JSON，大屏名称、ID、画布配置都在里面。

这个方法的核心优势是能同时看到前端和后端交互的完整链路，特别适合正在做二次开发的人。你不仅能拿到ID，还能顺便研究清楚：前端打开大屏时调了哪些接口、传了哪些参数、返回的数据结构长什么样。后面要做自定义功能时，这些信息全是现成的参考。

三层定位方式各有适用场景，我整理了个对照表方便大家选用：

2.4 部署时的ID位置补充说明

如果你是部署方，或者正在做本地环境迁移，会发现大屏ID还有一个"藏身处"：系统配置文件里。DataEase在安装部署时，会初始化一批内置数据，包括系统自带的示例大屏。这些内置大屏的ID是固定的，写在初始化的SQL脚本里。

比如你自己通过界面创建的大屏，ID是自动生成的；但系统自带的示例模板大屏，ID从一开始就是写死的。如果遇到过"为什么我复制了别人环境的大屏到本地，还是打不开"的问题，多半就是源环境大屏ID和本地环境初始化脚本里ID冲突或对不上导致的。

所以，在这个阶段你只要记住一个经验：所有通过界面创建、导入、复制出来的大屏，ID都以数据库实际存的那条记录为准，不要迷信URL里的值，更不要猜测、手动修改。手动改ID大概率会把关联关系全弄断，到时候大屏打开就是白屏，排查起来很费劲。

3. 拿到ID之后干什么：实际开发场景里的ID用法

找到ID只是起点，真正有价值的，是把ID用到实际业务场景里。结合大家在搜索里频繁遇到的关键词，我挑四个最典型的场景展开。

3.1 iframe嵌入：把大屏嵌到你的门户系统里

这是最常规的用法。DataEase的大屏本身是独立页面，但实际项目中大家几乎不可能让用户专门登录DataEase去看大屏，都是把它嵌到已有的OA系统、数据门户、指挥中心门户里。嵌入方式就是iframe。

关键点来了：iframe的src地址需要带上ID。但不同版本带参数的方式不太一样，我在实际项目中踩过的版本差异是：

v1.x时代，常见的大屏预览地址是：

http://服务器IP:端口/#/panel/view/大屏ID

这个地址直接塞进iframe里，理论上是能打开的。但如果你做了登录认证，iframe里就会出现登录页或者401错误。因为大屏页面本身是受登录保护的，门户系统如果没把DataEase的登录态传给这个iframe，浏览器打开就是白屏。

解决思路是先用一个"匿名访问"方式：DataEase后端一般会有嵌入场景的支持，需要你在部署时开启匿名访问权限，或者在URL后面追加特定的鉴权令牌。v2.x做得更完善一些，提供了一个独立的嵌入分享地址，地址形式类似：

http://服务器IP:端口/embed/#/dashboard-view/大屏ID

用这个/embed/路径可以绕开完整的后台UI，只渲染大屏内容，去掉顶部导航、侧边栏这些界面元素。对iframe嵌入来说，这种纯内容地址是最合适的。

我建议大家在测试时按这个顺序排查：先直接用浏览器打开拼接好ID的地址，确认能正常渲染；再放到iframe里测试；最后才处理鉴权、跨域、白屏等问题。不要一上来就嵌iframe，否则到时候分不清是地址错了还是系统配置问题。

3.2 弹窗效果：大屏ID在弹窗场景里的用法

搜索热词里出现了"dataease 弹窗效果"，这个需求通常有两种理解，一种是DataEase大屏内部的组件弹窗，一种是"我在自己的系统里点击按钮，弹窗展示大屏"。这里分享的是指后者——外部系统的弹窗展示。

做法是：在自己的前端页面里，定义一个弹窗容器，打开弹窗时动态设置iframe的src，src指向带大屏ID的嵌入地址。示例代码如下：

// 点击按钮后弹窗展示大屏 function openDashboardModal(dashboardId) { const modal = document.getElementById('dashboardModal'); const iframe = document.getElementById('dashboardIframe'); // 关键：拼接带ID的大屏嵌入地址 iframe.src = `http://你的DataEase地址/embed/#/dashboard-view/${dashboardId}`; modal.style.display = 'block'; }

实际做的时候有几个细节容易踩坑：

弹窗容器要有明确的高度和宽度，大屏画布默认是按1920x1080设计的，你在弹窗里直接塞进去，组件会缩放得很难看。稳妥做法是先期在设计大屏时就规划好显示比例，或者在iframe外层包一层比例固定的容器。

弹窗关闭时，记得把iframe的src置空，否则大屏页面的定时刷新任务会在后台持续运行，造成无谓的内存和网络开销。

function closeDashboardModal() { const iframe = document.getElementById('dashboardIframe'); iframe.src = 'about:blank'; document.getElementById('dashboardModal').style.display = 'none'; }

这个细节看起来小，但在真实项目里影响很大。大屏页面一般都有定时轮询数据，你不把iframe清掉，它就一直轮询，用户关掉弹窗后浏览器还在跑请求，服务器压力就是这么莫名其妙上来的。

3.3 移动端适配：大屏ID在手机端的正确打开方式

搜索里还有"dataease能设置手机"的疑问。DataEase的设计目标是PC大屏，但项目实际需求往往是"领导要在手机上随时看数据"。这时候大屏ID同样派得上用场。

在DataEase里做移动端适配，通常不是重新做一张手机版大屏，成本太高。合理的做法是：给这张大屏额外做一张移动端布局，或者通过前端缩放方案来适配。实际操作中，很多团队用的是"URL参数控制显示模式"的方式：URL里保留大屏ID，额外拼上模板类型参数，让大屏平台按移动端画布尺寸渲染。

// 在移动端打开时，替换为移动端模板地址 const baseUrl = 'http://你的DataEase地址/embed/#/dashboard-view/'; const dashboardId = '你的大屏ID'; const mobileTemplate = 'mobile'; // 假设系统支持移动端模板参数 window.location.href = `${baseUrl}${dashboardId}?template=${mobileTemplate}`;

要提醒的是，DataEase不同版本对移动端的支持策略不同。老版本基本没有移动端适配，只能靠浏览器强制缩放；新版本对大屏组件做了一定程度的响应式支持。在做方案之前，先确认一下自己部署版本的官方文档，别为了一个移动端适配功能去改源码，投入产出比太低。

3.4 数据联动和定时刷新：ID在后端接口里的作用

前面说的都是前端层面的用法。如果要做更深度的二次开发，比如在外部系统直接触发大屏数据刷新、动态切换数据源、控制大屏权限，ID就变成了后端接口调用的核心参数。

以刷新大屏数据为例，DataEase后端通常会有一个大屏缓存刷新或数据集刷新的接口，调用方式一般是POST请求，请求体里带上大屏ID和数据源ID：

curl -X POST "http://服务器IP:端口/api/dashboard/refresh" -H "Content-Type: application/json" -d '{ "dashboardId": "2f8a6f0c7d4a49a9b38dcef6f197fd9c" }'

这样做的好处是：你可以在外部系统里做一个"刷新大屏"按钮，用户点了之后，通过接口主动触发大屏数据更新，而不是等大屏页面的轮询周期自然到来。对数据实时性要求高的指挥中心场景，这个功能非常实用。

ID在权限控制场景里也很重要。DataEase的权限体系支持按资源维度控制，大屏本身就是一个资源。给用户、角色授权时，后端实际处理的就是"哪个用户能访问哪个大屏ID"。如果你在做对接，只需要知道这个大屏ID，然后调用权限管理接口把ID绑到对应角色上就行。

4. 二次开发中的ID实战链路

前面的场景都是拿ID配合系统已有功能，下面进入更进阶的领域：围绕ID做二次开发。很多人搜"dataease二次开发"，最终卡住的往往不是开发技术本身，而是没搞懂ID在前后端交互里的完整链路。

4.1 从数据库到前端渲染：一条ID的完整旅程

我用v1.x的逻辑简单拆一下这条链路，v2.x大体相似，细节略有差异。

第一步，后端在MySQL的dashboard表里存储大屏基础信息，包括ID、名称、画布宽高、背景色等。大屏的完整配置——哪些组件放在哪个位置、每个组件的样式和数据绑定关系——通常以JSON格式存在content字段里。

第二步，当用户在前端打开大屏页面时，前端拿到URL里的大屏ID，把它作为参数请求后端接口，例如：

GET /api/dashboard/queryWithCanvas/{大屏ID}

第三步，后端根据这个ID去数据库查出对应记录，把基础信息和JSON配置一块返回给前端。

第四步，前端解析返回的JSON，根据配置渲染画布和组件，然后组件各自去请求自己绑定的数据。

所以，ID的作用是贯穿始终的。丢了它，前端根本不知道去查哪条配置；后端也不知道返回哪个画布。这就解释了为什么"找不到ID"会成为一个高频问题——因为ID在系统里的角色太底层了，底层到正常操作界面根本不给你展示的机会。

做二次开发时，理解这条链路最大的价值是：你知道改哪个环节能影响什么效果。比如想让两个系统共享同一张数据大屏，你可以直接在外部系统里存大屏ID，然后通过URL直接访问；想让大屏带上不同的参数，就在URL的查询字符串里追加业务参数，再在大屏内部通过组件配置项接收参数、做数据过滤。ID是入口，参数是变量，两者配合才能玩出花来。

4.2 前端工程里的ID存储方式：localStorage与全局变量

搜热词时看到"根据id删除localstorage数据"，联想到DataEase前端确实会在浏览器localStorage里存一些大屏相关的状态数据。

了解这一块，对做前端二次开发很有帮助。当你打开DataEase大屏页面时，前端框架会把当前大屏的ID、最近访问记录、组件缓存状态等写入浏览器的localStorage。具体存储的key值每个版本不同，但通常能找到大屏ID的踪迹。

实际操作中，你可以在浏览器控制台里直接执行：

// 查看所有localStorage数据 for (let i = 0; i < localStorage.length; i++) { const key = localStorage.key(i); console.log(key, localStorage.getItem(key)); }

看到有没有大屏ID相关的key，比如dashboardId、current_dashboard之类的。

如果你的二次开发是想"记住用户上次打开的大屏"，靠这个localStorage里的ID就能实现。如果你想"根据某个大屏ID清理缓存数据"，就会涉及到删除localStorage里对应键值对的操作：

localStorage.removeItem('dashboardId');

或者如果你能确认数据格式，也可以按ID去过滤：

// 示例：删除localStorage中所有含特定大屏ID的记录 Object.keys(localStorage) .filter(key => localStorage.getItem(key).includes('你的大屏ID')) .forEach(key => localStorage.removeItem(key));

这块内容看着小，但对做"记住上次浏览位置""最近访问的大屏列表"这类功能非常实用。很多初级开发者会在后端建一张访问记录表来存这些数据，实际上是多此一举，浏览器本地存储完全能解决。

4.3 用ID做自动化任务：批量操作大屏的最佳入口

还有一种比较进阶的用法：用ID批量操作大屏。比如你系统里跑着几十张大屏，要做数据迁移、备份、批量导出，这时ID就是脚本里最核心的入参。

写一个简单的Python脚本，先连数据库把所有大屏ID捞出来，再逐个调用DataEase的导出接口：

import requests import pymysql # 1. 从数据库读取所有大屏ID conn = pymysql.connect(host='localhost', user='root', password='yourpassword', database='dataease') cursor = conn.cursor() cursor.execute("SELECT id, name FROM dashboard") dashboards = cursor.fetchall() # 2. 批量处理 for dashboard_id, name in dashboards: # 调用DataEase导出接口，实现大屏备份 response = requests.get( f"http://服务器IP:端口/api/dashboard/export/{dashboard_id}" ) # 保存文件等操作... print(f"已处理大屏: {name} ({dashboard_id})")

这个思路也可以用于批量修改大屏名称、批量替换数据源、批量设置权限。只要ID在手，你就能通过API或数据库脚本对任意大屏做精准的定向操作。

5. 找ID和用ID过程中最容易踩的坑

关于ID的坑，我在项目里见过不少，挑几个高频率的写出来，给大家排雷。

5.1 复制环境后ID冲突

DataEase大屏导出再导入，ID通常会重新生成。但如果你直接把整个数据库从一个环境复制到另一个环境，ID就不会变。这时候如果两个环境同时运行，就存在ID冲突的隐患。

经验是：跨环境迁移大屏时，导出的文件里如果包含ID字段，迁移前最好先确认目标环境有没有相同ID的记录。有就先删除目标环境的旧记录，再做导入，否则可能出现"找不到组件""画布空白"这类异常。

5.2 URL里ID被截断或编码

有人把大屏地址发给别人，发现对方打不开。检查后发现，ID是32位字符串，在微信、钉钉这类聊天工具里发送时，有时候某些字符被自动识别为链接尾部的标记，被截断了。特别是ID里刚好带有类似.或-这样的字符时，更容易出问题。

解决方式很简单：发送时给整个URL加包裹，或者干脆用短网址服务转一下。但对开发来说，最关键的是别把URL拼接逻辑写死，最好后端根据环境自动拼完整地址，不要前端拿一个裸ID去手动拼。

5.3 前端缓存导致ID更新不生效

修改了大屏ID（虽然不推荐手动改），或者用脚本批量更新了ID关联关系，但前端打开还是老样子。这是浏览器缓存和前端状态管理导致的。DataEase前端框架在首次加载后会把一部分配置缓存在内存或localStorage里，源端数据虽然变了，前端感知不到。

遇到这种情况，先强制刷新页面（Ctrl+F5或Command+Shift+R），再不行就清一下localStorage里的大屏相关键值。如果还是不行，检查一下是不是Nginx层做了缓存，有时需要临时关闭缓存来验证。

5.4 权限配置里写死ID导致误授权

还有些管理员图省事，在权限配置文件里直接写死一系列大屏ID。这种做法短期内可以，但一旦系统做过数据迁移、大屏被删除重建，写死的ID就失效了。新大屏ID和配置文件里的对不上，权限自然乱套。

正确做法是尽量通过DataEase的授权界面或API来管理权限，让系统自动维护ID和权限的关系。实在要在配置文件里指定，也建议在关键位置加注释说明这些ID对应的业务含义，方便后人维护。

6. 兜底方案：ID彻底找不到了怎么办

如果一个方法都试不通，ID就是找不到，也不要慌。我遇到过不少次大屏作者离职、文档缺失、数据库也连不上的"绝境"，最后都用一些兜底方法解决了。

第一招：从缩略图反查。DataEase大屏列表页会展示缩略图，而这个缩略图在后端存储时，文件名里往往包含大屏ID。去服务器的静态资源目录里找大屏缩略图文件，看文件名，多半能还原ID。

第二招：从访问日志反查。如果你部署了Nginx，访问日志里会记录所有请求路径。用大屏名称关键词去过滤Nginx日志，找到最近的访问记录，从URL路径里提取ID。

grep "大屏名称关键词" /var/log/nginx/access.log | tail -20

第三招：从分享链接反查。如果你曾经把某个大屏分享出去过，或者别人给你发过链接，即使本地系统已经查不到，那条历史分享链接里仍然有ID。翻聊天记录、邮件，找#/panel/view/后面的串。

第四招：从工单系统或笔记里找。很多团队在部署DataEase时，会把初始大屏的地址写成文档分享给业务方，这份文档里通常记录了完整的带ID的URL。去公司知识库、项目笔记、部署文档里搜"大屏"关键词，往往能翻出惊喜。

最后一招，也是最不推荐但实在没办法时的选择：直接在大屏列表页再复制一张同名大屏，然后修改里面的组件和数据配置。新大屏会是全新的ID，虽然等于重做了一次，但至少不用从头搭。

7. 针对常见二次开发疑问的延伸操作

再看一遍热门搜索词，有两条和ID关系密切的需求值得单独展开："dataease二次开发设置嵌入iframe问题"和"avue-data数据大屏前端是怎么部署的"。虽然第二个和DataEase不属于同一套产品，但ID定位思路是通用的。这里把iframe嵌入和前端部署的细节再拉深一层。

7.1 iframe嵌入的完整配置顺序

很多人在iframe嵌入上反复踩坑，就在于配置顺序不对。正确的顺序应该是：

第一，确认大屏地址能独立访问。先用浏览器直接打开带ID的大屏URL，确认能正常渲染。这一步不过，后面都白搭。

第二，切换为嵌入模式。如果版本支持/embed/路径，优先使用。这个模式专门为嵌入场景设计，会隐藏系统的导航和各种操作按钮，只保留大屏本身。同时，避免对大屏进行编辑操作造成意外修改。

第三，处理跨域问题。DataEase部署在一个域名，你的门户系统在另一个域名，浏览器会拦截跨域请求。这时候需要在DataEase后端（或Nginx层）配置跨域头。Nginx配置参考：

add_header Access-Control-Allow-Origin *; add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS'; add_header Access-Control-Allow-Headers 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';

第四，传递登录凭证。业务系统和大屏系统如果共用一套统一登录，正常情况下登录凭证会通过Cookie携带。但跨域情况下Cookie默认不共享，需要在iframe和父页面之间做凭证传递，或用token方式。

第五，设置加载态。大屏数据加载需要时间，iframe里如果响应慢，用户看到的是一片空白。可以在iframe外层加一个loading显示，监听iframe的onload事件来隐藏loading。

7.2 前端部署的ID关联关系

"avue-data数据大屏前端是怎么部署的"这个热搜说明很多人对前端部署和ID的关系有困惑。简洁版实践经验是：无论你用avue-data、DataEase还是其他开源大屏工具，前端部署的本质都是静态资源托管加后端API地址配置。大屏ID是存到后端数据库里的，前端的部署包里不会包含具体的ID，只包含"如何获取ID并渲染大屏"的逻辑。

所以前端部署时，只需要关注三件事：静态文件放哪个服务器、API地址指向哪个后端、后端数据库里有没有对应的大屏数据。ID本身不用你手动复制到前端配置里，前端会通过接口去动态查询。如果你在部署后打开系统看不到任何大屏列表，检查一下前端配置的后端API地址对不对、数据库里是否真的有大屏记录，别在ID上死磕。

8. 个人实操中的几点体会

最后分享几个我长时间使用DataEase后沉淀下来的小经验，不算是系统教程里的内容，但确实能帮大家少走弯路。

关于ID，我现在的习惯是：每部署一套DataEase环境，第一时间在项目文档里记录一张"大屏ID对照表"，包括大屏ID、名称、业务含义、关联数据源。这个习惯救了我很多次，项目后期人员变动时，新接手的人靠这张表就能快速定位问题，不用再去数据库里翻。

关于二次开发，我的建议是尽量不直接改DataEase源代码，而是通过接口层做扩展。源代码改起来一时爽，版本升级时全部冲突，维护成本极高。利用大屏ID作为入参，在外部系统里做逻辑控制，才是可持续的方案。

关于嵌入和移动端，先和业务方确认清楚使用场景再动手。如果只是"偶尔看一眼"，直接给一个带ID的链接就完事；如果是"每天开会都要投屏展示"，那就认真做iframe嵌入和数据源优化，别用临时方案凑合。

DataEase的大屏ID这东西，说简单也简单，说绕也绕。一旦你理解了它在这个系统里的角色定位，再面对"找不到大屏ID""ID关联出错""跨系统集成"这些问题，思路就会清晰很多——先从URL拿ID，再从数据库反查记录，最后从接口链路里验证逻辑。三步走完，绝大多数ID相关的困惑都能解开。