Power BI Embedded：向您的应用程序添加分析

每个 SaaS 应用程序最终都需要分析。用户希望仪表板显示他们的使用模式、性能指标和业务成果。从头开始构建自定义分析层（图表库、数据管道、缓存、导出功能、深入交互）需要 6-12 个月的工程工作和持续维护。 Power BI Embedded 提供了另一种选择：直接嵌入到您的应用程序中的企业级分析功能，并由 Microsoft 基础设施提供支持。

Power BI Embedded 不仅仅是“将 iframe 放在页面上”。它是一个完整的平台，可在您自己的应用程序 UI 中提供交互式、安全的多租户分析体验。当您利用 Power BI 成熟的可视化引擎、DAX 计算层和数据连接基础设施时，您的客户可以与您的产品原生的分析进行交互。

本指南涵盖了在应用程序中嵌入 Power BI 的体系结构、身份验证模型、多租户安全性、容量规划、SDK 集成和定价注意事项。如果您正在计划实施嵌入式分析，请探索我们的 Power BI 嵌入式分析服务 以获取架构指导和开发支持。

要点

• Power BI Embedded 支持两种方案：“为您的客户嵌入”（应用程序拥有数据）和“为您的组织嵌入”（用户拥有数据）
• 建议对多租户 SaaS 应用程序进行服务主体身份验证；主用户帐户更简单，但会产生单点故障
• 行级安全性 (RLS) 是确保共享数据集中租户数据隔离的主要机制
• Fabric F SKU 为嵌入式场景提供最具成本效益的容量，从 F2 开始进行开发
• JavaScript SDK 支持深度编程控制：应用过滤器、捕获事件、控制导航和自定义主题
• 容量大小取决于并发用户数、查询复杂性和数据量——而不仅仅是总用户数
• 自定义主题和隐藏镶边使嵌入式报告感觉对您的应用程序来说是原生的

---

嵌入场景：客户与组织

为您的客户嵌入（应用程序拥有数据）

“应用程序拥有数据”场景是 SaaS 应用程序的主要用例。您的应用程序使用服务主体或主用户帐户通过 Power BI 进行身份验证，生成嵌入令牌，并向最终用户提供嵌入报告。您的客户从不直接与 Power BI 交互，也不需要 Power BI 许可证。

架构流程：

1. 您的客户使用您的身份验证系统登录您的应用程序。
2. 您的应用程序后端调用 Power BI REST API 来生成嵌入令牌，其范围仅限于该客户的特定报表、数据集和 RLS 角色。
3. 后端将嵌入令牌和嵌入 URL 返回给前端。
4. 前端使用嵌入令牌初始化 Power BI JavaScript SDK，并在指定的容器元素中呈现报表。
5. 嵌入令牌在可配置的时间段（默认 1 小时）后过期，并且您的应用程序会透明地刷新它。

主要特征：

• 客户不需要 Power BI Pro 或 Premium 每用户许可证
• 所有容量成本均由您（应用程序提供商）通过 Fabric/Embedded SKU 承担
• 您可以通过 RLS 和程序化过滤完全控制用户看到的内容
• 身份验证完全在应用程序的身份验证系统内进行
• 嵌入令牌提供对特定工件的有范围、有时间限制的访问

这是 ISV、SaaS 平台和内部门户使用的模型，其中分析消费者不应该知道或关心 Power BI 是底层技术。

为您的组织嵌入（用户拥有数据）

“用户拥有数据”场景用于将 Power BI 内容嵌入到用户已拥有 Power BI 许可证（Pro 或 PPU）的内部应用程序中。嵌入式体验使用用户自己的 Power BI 身份和权限。

架构流程：

1. 用户通过您的应用程序向 Azure AD 进行身份验证。
2. 您的应用程序使用 OAuth 2.0 代表流程代表用户获取访问令牌。
3. 应用程序使用用户的令牌调用 Power BI REST API 以获取嵌入配置。
4. 报表使用用户的完整 Power BI 权限进行呈现。

主要特征：

• 每个用户必须拥有 Power BI Pro 或 Premium Per User 许可证
• 用户根据自己的 Power BI 权限和 RLS 分配查看内容
• 不需要额外的 Fabric/Embedded 容量（使用用户的 Pro/PPU 许可证分配）
• 应用程序开发人员的控制更少，用户的自主权更多
• 架构更简单，但每用户许可成本更高

此模型通常用于 Intranet 门户、SharePoint 集成和内部应用程序，其中用户已拥有 Power BI 许可证并应保留其现有访问权限。

在场景之间进行选择

对于大多数面向外部客户的 SaaS 应用程序来说，“应用程序拥有数据”是正确的选择。本指南的其余部分主要关注此场景。

---

身份验证：服务主体与主用户

服务主体身份验证

服务主体是 Power BI 信任的 Azure AD 应用程序标识，可以通过编程方式访问资源。它是生产嵌入式应用程序的推荐身份验证方法。

设置要求：

1. 在 Azure AD 中注册应用程序。
2. 为应用程序创建客户端密钥或证书。
3. 创建 Azure AD 安全组并向其中添加服务主体。
4. 在 Power BI 管理门户中，在租户设置 > 开发人员设置下启用安全组的服务主体访问权限。
5. 授予服务主体对包含嵌入内容的特定 Power BI 工作区的访问权限。

优点：

• 不依赖于特定用户帐户（消除单点故障）
• 客户端机密和证书可以在不中断服务的情况下轮换
• 服务主体可以限定在特定工作区（最小权限）
• 在 Azure 托管应用程序中使用 Azure AD 托管标识
• 支持基于证书的身份验证，安全性更高

限制：

• 无法访问“我的工作区”（个人工作区）
• 无法调用某些管理 API
• 需要 Azure AD Premium 才能使用某些高级功能
• 初始设置比主用户更复杂

主用户身份验证

主用户是具有 Power BI Pro 或 PPU 许可证的常规 Azure AD 用户帐户，应用程序使用该许可证通过 Power BI 进行身份验证。应用程序以此用户身份登录以生成嵌入令牌。

优点：

• 更简单的初始设置（创建用户、分配许可证、授予工作区访问权限）
• 可以访问所有 Power BI 功能，包括管理 API
• 无需注册 Azure AD 应用程序

缺点：

• 单点故障：如果用户帐户被锁定、密码过期或触发 MFA，您的应用程序将失去对分析的访问权限
• 无法使用需要交互式登录的条件访问策略
• 密码轮换需要应用程序更新
• 违反了不使用人工帐户进行机器流程的安全最佳实践
• 用户帐户的许可费用

建议： 对所有生产部署使用服务主体身份验证。主用户帐户对于概念验证和开发环境是可以接受的，在这些环境中，简单性比可靠性更重要。

代币生成和管理

无论采用哪种身份验证方法，您的应用程序都会通过 Power BI REST API 生成嵌入令牌。令牌封装了嵌入式会话的权限。

嵌入令牌注意事项：

• 令牌有效期： 默认为 1 小时，可配置最长 24 小时。生命周期越短越安全，但需要更频繁的刷新。
• 令牌范围： 每个令牌的范围仅限于特定的报告、数据集和工作区。生成尽可能窄的范围。
• RLS 身份： 使用行级安全性时，RLS 身份（用户名和角色）嵌入在令牌中。这就是确保租户隔离的方法。
• 令牌刷新： 您的前端应该监视令牌过期并在过期之前请求新令牌。 JavaScript SDK 为此提供了事件。

令牌生成示例流程：

POST https://api.powerbi.com/v1.0/myorg/GenerateToken
{
    "datasets": [{"id": "dataset-guid"}],
    "reports": [{"id": "report-guid"}],
    "identities": [{
        "username": "[email protected]",
        "roles": ["TenantRole"],
        "datasets": ["dataset-guid"]
    }]
}

响应包含嵌入令牌和过期时间戳。您的后端缓存此令牌（考虑过期）并将其提供给经过身份验证的前端请求。

---

多租户行级安全性

为什么 RLS 对于嵌入式至关重要

在多租户 SaaS 应用程序中，多个客户的数据通常驻留在同一个 Power BI 数据集中。如果没有行级安全性，嵌入令牌将授予对数据集中所有数据的访问权限。 RLS 确保每个客户只能看到自己的数据，即使底层数据集是共享的。

对于多租户嵌入式场景，RLS 不是可选的。租户隔离失败就是数据泄露。将 RLS 设计为基础安全控制，而不是事后的想法。

静态 RLS

静态 RLS 使用 Power BI Desktop 中的 DAX 表达式定义固定筛选规则。每个角色都有一组表过滤器，用于限制哪些行可见。

示例：

客户表上带有此过滤器的“TenantRole”：

[TenantId] = USERNAME()

生成嵌入令牌时，您的应用程序会将 USERNAME() 值设置为当前租户的标识符。 DAX 过滤器将所有查询限制为 TenantId 匹配的行。

静态 RLS 对于简单的租户隔离来说简单而有效。在以下情况下效果很好：

• 租户隔离基于通过关系传播的单列 (TenantId)
• 所有租户都会看到相同的报告结构，只是过滤到他们的数据
• RLS角色数量少且稳定

动态 RLS

动态 RLS 使用 DAX 表达式，该表达式在查询时根据用户的身份进行计算。这可以实现更复杂的安全场景，而无需为每个租户创建单独的角色。

常见的动态 RLS 模式：

USERPRINCIPALNAME() 模式：

[Email] = USERPRINCIPALNAME()

嵌入令牌将有效身份的用户名设置为用户的电子邮件。该过滤器与安全映射表中的电子邮件列进行匹配。

安全表图案： 创建一个专用的安全表，将用户映射到他们可以访问的数据：

应用通过关系将此安全表连接到事实表的 RLS 过滤器。此模式支持租户内的用户级权限，而不仅仅是租户级隔离。

RLS 测试和验证

部署前测试：

1. 在 Power BI Desktop 中，使用“查看方式”使用示例用户名测试每个 RLS 角色。
2. 验证表之间的交叉过滤是否遵循 RLS 边界。
3. 测试边缘情况：没有匹配行的用户（应该看到空报告，而不是错误）、具有多个角色的用户以及筛选列中的空值。
4. 验证使用 ALL() 或 REMOVEFILTERS() 的 DAX 测量不会绕过 RLS（它们不应该绕过，但需要验证）。

生产验证：

• 将 RLS 测试自动化作为部署管道的一部分
• 生成用于测试租户身份的嵌入令牌并验证查询结果与预期数据匹配
• 监控容量指标中的 RLS 绕过尝试（异常查询模式、意外数据量）
• 每季度对 RLS 配置进行安全审查

---

容量大小和结构 SKU

了解容量

Power BI Embedded 需要专用容量——为嵌入式工作负载保留的计算资源。容量以容量单位 (CU) 来衡量，它决定了可用于呈现报告、执行查询和刷新数据集的处理能力。

容量不是每个用户的。它是一个共享计算池，所有嵌入式会话都从中获取。这意味着定价与并发性和查询复杂性有关，而不是与用户总数有关。

面料 F SKU 选项

Microsoft Fabric F SKU 是 Power BI Embedded 容量的当前定价模型。他们用更灵活、具有暂停功能的模型取代了传统的 A SKU。

重要说明：

• 并发用户数并不意味着总用户数。这意味着用户在同一时刻主动查询。在任何给定时间，典型的比率是总用户的 5-10% 是并发的。
• 这些是大概的指导数字。实际容量在很大程度上取决于查询复杂性、模型大小和每个报告的可视化计数。
• F SKUs can be paused when not in use (unlike legacy P SKUs), which is valuable for development and seasonal workloads.
• F64 及更高版本包含 Power BI Premium 功能（分页报告、AI、部署管道），无需额外许可费用。

容量调整方法

第 1 步：估计并发用户数。

并发用户数 = 总用户数 x 峰值并发数

对于在工作时间访问的 SaaS 分析仪表板：5-10% 的并发率。 对于全天频繁检查的操作仪表板：15-25% 的并发率。 对于事件驱动的仪表板（实时监控、警报）：30-50% 的并发率。

第 2 步：评估查询复杂性。

简单报告（5-10 个视觉效果、基本聚合、单个事实表）：1x 基线。 中等报告（10-20 个视觉效果、时间智能、多个事实表）：2-3 倍基线。 复杂报告（20 多个视觉效果、复杂 DAX、大型数据集、跨源查询）：4-6 倍基线。

第 3 步：计算所需容量。

从与上表中您估计的并发用户数相匹配的 SKU 开始。乘以您的复杂度系数。如果结果超出 SKU 的并发查询容量，则移至下一层。

第 4 步：通过负载测试进行验证。

理论尺寸是一个起点。在生产启动之前，使用实际数据量、查询模式和并发级别进行负载测试。 Microsoft 为此提供了 Power BI Embedded 容量负载测试工具。

第 5 步：制定增长计划。

在当前峰值之上增加 30-50% 的空间，以适应未来 6-12 个月的增长。 F SKU 无需停机即可升级，因此您可以逐步调整规模。

成本优化策略

• 在非工作时间暂停开发能力。 F SKU 活动时按秒计费，暂停时免费。使用 Azure 自动化或逻辑应用自动暂停/恢复可以将开发成本降低 60-70%。

• 在扩展容量之前优化模型。 F8 上优化良好的模型通常优于 F32 上优化不佳的模型。在使用计算解决性能问题之前先投资模型优化。

• 对大型数据集使用聚合表。以常见粒度（每日、每周、每月）预聚合数据可将摘要级视觉效果的查询处理减少 80-90%，同时保留详细信息的向下钻取功能。

• 通过 Power BI REST API 实施报表级缓存。对于数据更新不频繁的仪表板，缓存结果可减少每个用户会话的容量消耗。

• 考虑针对不同工作负载的单独容量。将刷新操作与交互式查询隔离可以防止刷新峰值降低用户体验。如果您有在工作时间刷新的大型数据集，这一点尤其重要。

---

JavaScript SDK 集成

基本嵌入

Power BI JavaScript SDK (powerbi-client) 提供了用于在 Web 应用程序中嵌入和控制 Power BI 内容的编程接口。

安装：

npm install powerbi-client

基本嵌入流程：

import * as pbi from 'powerbi-client';

const powerbi = new pbi.service.Service(
    pbi.factories.hpmFactory,
    pbi.factories.wpmpFactory,
    pbi.factories.routerFactory
);

const embedConfig = {
    type: 'report',
    id: reportId,
    embedUrl: embedUrl,
    accessToken: embedToken,
    tokenType: pbi.models.TokenType.Embed,
    settings: {
        panes: {
            filters: { visible: false },
            pageNavigation: { visible: true }
        },
        background: pbi.models.BackgroundType.Transparent,
        layoutType: pbi.models.LayoutType.Custom,
        customLayout: {
            displayOption: pbi.models.DisplayOption.FitToWidth
        }
    }
};

const reportContainer = document.getElementById('report-container');
const report = powerbi.embed(reportContainer, embedConfig);

程序控制

SDK 公开了对嵌入式报告的广泛编程控制：

应用过滤器：

const filter = {
    $schema: "http://powerbi.com/product/schema#basic",
    target: {
        table: "Sales",
        column: "Region"
    },
    operator: "In",
    values: ["North", "South"],
    filterType: pbi.models.FilterType.BasicFilter
};

await report.setFilters([filter]);

捕获事件：

report.on('loaded', function() {
    console.log('Report loaded successfully');
});

report.on('dataSelected', function(event) {
    const data = event.detail;
    // Handle user selection — navigate to detail page, update other UI, etc.
});

report.on('pageChanged', function(event) {
    const pageName = event.detail.newPage.displayName;
    // Track page navigation in your analytics
});

令牌刷新：

report.on('tokenExpired', async function() {
    const newToken = await fetchNewEmbedToken();
    await report.setAccessToken(newToken);
});

导航控制：

// Navigate to a specific page
const pages = await report.getPages();
const targetPage = pages.find(p => p.displayName === 'Revenue Analysis');
await targetPage.setActive();

// Set a specific slicer value
const visuals = await targetPage.getVisuals();
const slicer = visuals.find(v => v.type === 'slicer');
await slicer.setSlicerState({
    filters: [{
        $schema: "http://powerbi.com/product/schema#basic",
        target: { table: "Date", column: "Year" },
        operator: "In",
        values: [2026],
        filterType: pbi.models.FilterType.BasicFilter
    }]
});

分阶段渲染以提高性能

对于具有许多视觉效果的复杂报告，分阶段渲染通过首先渲染首屏内容来提高感知性能：

const embedConfig = {
    // ... standard config
    settings: {
        // ... other settings
        commands: [{
            visualRendered: {
                phase: 1,
                visualNames: ['revenue-kpi', 'trend-chart', 'summary-table']
            }
        }]
    }
};

report.on('visualRendered', function(event) {
    if (event.detail.phase === 1) {
        // Hide loading spinner, show report
        document.getElementById('loading').style.display = 'none';
    }
});

---

自定义主题和品牌

为什么自定义主题很重要

默认 Power BI 视觉效果使用 Microsoft 的调色板和样式。在嵌入式上下文中，这会导致与应用程序的视觉不一致。自定义主题使嵌入式分析与产品的设计系统保持一致，使体验感觉是原生的，而不是附加的。

主题 JSON 结构

Power BI 主题定义为 JSON 文件，可以控制颜色、字体、视觉默认值和元素样式：

{
    "name": "MyApp Theme",
    "dataColors": [
        "#2563EB", "#7C3AED", "#059669", "#D97706",
        "#DC2626", "#0891B2", "#4F46E5", "#65A30D"
    ],
    "background": "#FFFFFF",
    "foreground": "#1E293B",
    "tableAccent": "#2563EB",
    "textClasses": {
        "callout": {
            "fontSize": 28,
            "fontFace": "Inter, sans-serif",
            "color": "#0F172A"
        },
        "title": {
            "fontSize": 14,
            "fontFace": "Inter, sans-serif",
            "color": "#1E293B"
        },
        "header": {
            "fontSize": 12,
            "fontFace": "Inter, sans-serif",
            "color": "#475569"
        },
        "label": {
            "fontSize": 11,
            "fontFace": "Inter, sans-serif",
            "color": "#64748B"
        }
    },
    "visualStyles": {
        "*": {
            "*": {
                "border": [{
                    "color": {"solid": {"color": "#E2E8F0"}},
                    "radius": 8
                }],
                "background": [{
                    "color": {"solid": {"color": "#FFFFFF"}},
                    "transparency": 0
                }]
            }
        }
    }
}

以编程方式应用主题

主题可以在嵌入时应用或动态切换（对于暗模式支持很有用）：

// Apply theme at embed time
const embedConfig = {
    // ... standard config
    theme: { themeJson: customThemeJson }
};

// Switch theme dynamically (e.g., light/dark mode toggle)
await report.applyTheme({ themeJson: darkThemeJson });

隐藏 Power BI Chrome

为了获得完全本机的外观，请隐藏 Power BI 的内置 UI 元素并将其替换为您自己的应用程序控件：

const settings = {
    panes: {
        filters: { visible: false },      // Hide filter pane
        pageNavigation: { visible: false } // Hide page tabs
    },
    bars: {
        actionBar: { visible: false },     // Hide action bar
        statusBar: { visible: false }      // Hide status bar
    },
    background: pbi.models.BackgroundType.Transparent,
    visualRenderedEvents: true
};

然后在应用程序的 UI 框架中构建自定义导航、过滤和导出控件。当用户与自定义控件交互时，使用 JavaScript SDK 以编程方式应用过滤器、更改页面并触发导出。

此方法需要更多的开发工作，但会产生无缝体验，用户无法区分应用程序的本机功能和嵌入式 Power BI 内容。

---

嵌入式性能优化

前端性能

• 延迟加载 SDK。 Power BI JavaScript SDK 大约为 300KB。仅当用户导航到分析页面时才异步加载它。
• 预加载嵌入令牌。 在用户请求报告之前生成嵌入令牌。如果您的应用程序知道用户可能会查看分析（基于导航模式），请在页面转换期间预加载令牌。
• 使用引导嵌入。 SDK 支持引导模式，在嵌入令牌可用之前初始化 iframe，从而将感知加载时间减少 200-500 毫秒。

// Bootstrap first (fast — creates iframe immediately)
const report = powerbi.bootstrap(container, { type: 'report' });

// Load later when token is available
const embedConfig = { /* full config */ };
report.load(embedConfig);

• 实现报告缓存。 加载报告后，iframe 会将其保留在内存中。如果用户离开并返回，请重用现有的 iframe，而不是重新嵌入。这完全消除了同一会话中回访的加载时间。

后端性能

• **缓存嵌入令牌。**嵌入令牌在其整个生命周期内有效（默认为 1 小时）。将它们缓存在 Redis 或内存中，并在同一报告/身份组合的请求之间重复使用。
• 批量令牌生成。 如果用户的仪表板包含多个嵌入报告，请使用GenerateToken端点的多资源功能在单个API调用中生成所有嵌入令牌。
• 监控 API 速率限制。 Power BI REST API 对每个服务主体都有速率限制。监控 429 响应并实施指数退避。对于大规模应用程序，跨多个服务主体分配负载。

嵌入式报告设计

为嵌入式使用而设计的报告应优先考虑性能而不是视觉复杂性：

• 将视觉效果限制为每页 8-12 个（每个视觉效果生成一个单独的查询）
• 尽可能使用导入模式而不是 DirectQuery（快 10-100 倍）
• 以适当的粒度预先聚合数据
• 避免在登陆页面上进行复杂的 DAX 测量（将其保存以用于钻取详细信息）
• 使用书签进行预先计算的视图而不是动态计算
• 在您预期的并发级别测试报告加载时间，而不仅仅是单用户

对于实施嵌入式分析的组织，ECOSIRE 提供架构咨询和开发服务，以确保从第一天起就获得最佳性能。

---

嵌入式安全注意事项

令牌安全

嵌入令牌授予对 Power BI 内容的访问权限。将它们视为敏感凭证：

• 切勿在客户端源代码或 URL 参数中公开嵌入令牌
• 在服务器端生成令牌并通过经过身份验证的 API 端点传递它们
• 使用最短的实际令牌生命周期（默认 1 小时对于大多数应用程序来说是合理的）
• 实施令牌刷新逻辑而不是生成长期令牌
• 监控代币生成模式是否存在异常（异常数量、意外的报告 ID）

租户隔离验证

对于多租户应用程序，持续验证租户隔离：

• 为租户 A 生成嵌入令牌并验证租户 B 的数据不可访问的自动化测试
• 查询日志记录以检测跨租户数据访问尝试
• 定期RLS配置审核（RLS角色可以在Power BI Desktop中修改并意外削弱）
• 对 RLS 过滤器错误发出警报（这可能表明配置错误）

网络安全

• 使用 Azure AD 条件访问限制 Power BI REST API 访问已知 IP 范围
• 使用专用端点进行与本地数据源的网关连接
• 在 Power BI 管理门户中启用审核日志记录以跟踪所有 API 调用并嵌入令牌生成
• 实施内容安全策略标头以限制 iframe 嵌入到您的应用程序域

---

常见问题解答

对于拥有 10,000 个用户的 SaaS 应用程序，Power BI Embedded 的成本是多少？

成本取决于并发用户数，而不是总用户数。如果 10,000 个用户中有 5% 在高峰时并发（500 个并发用户），则您需要大约 F32 容量，每月大约 8,200 美元（即用即付）。如果预订（1 年承诺），则费用降至每月约 5,500 美元。您的实际成本可能会更高或更低，具体取决于报告复杂性、数据集大小和使用模式。从 F8 开始进行试点，使用实际并发进行负载测试，并根据实际测量进行扩展。

我可以在没有 Azure 的情况下使用 Power BI Embedded 吗？

Power BI Embedded 需要 Azure AD 进行身份验证并通过 Azure 预配 Fabric/Embedded 容量。您的应用程序本身可以托管在任何地方（AWS、GCP、本地），但 Power BI 资源必须位于 Azure 中。服务主体或主用户帐户必须位于 Azure AD 中，并且容量必须是 Azure 资源。对于没有现有 Azure 足迹的组织，该设置会增加大约 2-4 小时的 Azure 配置工作以及超出容量本身的最少持续 Azure 管理。

Power BI Embedded A SKU、EM SKU 和 Fabric F SKU 之间有什么区别？

SKU 是通过 Azure 预配的原始 Power BI Embedded 容量。 EM SKU 是 Office 365 内部嵌入的许可选项。两者均已被 Fabric F SKU 取代，后者为所有 Power BI 和 Fabric 工作负载提供统一的容量模型。 F SKU 提供按秒计费、暂停/恢复功能以及更简单的定价结构。对于新实施，请仅使用 F SKU。现有 A SKU 客户应计划迁移到 F SKU，以获得更好的定价和功能。

用户可以从嵌入的报告中导出数据吗？

是的，但您可以通过嵌入设置来控制它。 JavaScript SDK 允许您启用或禁用每个报告的导出功能（导出到 Excel、PDF、PowerPoint）。您还可以通过导出 API 实现自定义导出功能，这使您可以更好地控制格式、应用的过滤器和审核日志记录。对于敏感数据，请禁用内置导出并提供您自己的导出机制，以应用额外的授权检查和水印。

如何在嵌入式场景中处理报表开发？

报表开发遵循标准 Power BI 工作流程：在 Power BI Desktop 中构建报表、发布到开发工作区、使用示例嵌入令牌进行测试、通过部署管道提升到生产环境。主要区别在于，嵌入式报告需要对 RLS 行为、并发下的性能、跨屏幕尺寸的响应式布局以及与应用程序 UI 的交互进行额外测试。建立 CI/CD 管道，其中包括自动 RLS 验证和性能回归测试，作为每个报告部署的一部分。