SPFx) SharePoint 框架 (是 SharePoint 用户界面扩展性的新开发模型。 它由第一方和第三方使用，是对现有自定义和扩展性选项（如 SharePoint 外接程序模型）的补充。 SharePoint 框架允许使用客户端框架来扩充和扩展 SharePoint 用户界面的结构化和支持的方法。 它基于现代 Web 标准，提供了一组独特的功能，使 SharePoint 自定义项广泛可供开发人员和企业使用，但同时与 SharePoint 中的以前的模型和模式保持一致。 在此页上，我们为管理员提供在 SharePoint 环境中成功管理基于 SharePoint 框架 的组件所需的背景、权益和知识。
背景
SharePoint 长期以来一直被用作应用程序和/或开发平台，提供了众多开发和自定义选项，包括在 SharePoint 服务器上执行的完全信任代码、沙盒解决方案、加载项、使用现成功能或 JavaScript/CSS 嵌入实现的界面自定义项等。
在多租户 SharePoint Online 内，从不支持完全信任代码，并且已弃用沙盒代码服务。 SharePoint Online 自定义的最常见模式是通过加载项、远程代码执行（代码在其他位置执行,例如在 Azure中）通过标准 API 执行，以及 JavaScript 嵌入。 虽然 JavaScript 嵌入是一种功能非常强大的 SharePoint 扩展方式，但事实证明很难跟上不断更新的 SharePoint Online 模型的步伐。 SharePoint 框架旨在解决这些问题，不仅可以提供有关如何创建自定义用户界面扩展的标准化框架，还能按兼顾未来发展趋势的支持方式在 SharePoint Online 的基础之上生成应用程序。
SharePoint 框架使用 客户端 Web 部件扩展 SharePoint 用户界面， 和 扩展。
客户端 Web 部件
客户端 Web 部件采用知名的 Web 部件范例（这是 SharePoint 多年来的成功要素之一），最终用户可以将客户端 Web 部件添加到页面并单独自定义。 它们可以添加到页面，并由最终用户独立自定义。 这些客户端 Web 部件适用于新式页面和经典页面，甚至在 SharePoint 移动应用中。
注意
有关详细信息，请参阅 SharePoint 客户端 Web 部件的概述。
扩展
SPFx 扩展使开发人员能够在"新式"中实现某些用户界面自定义项在 SharePoint>经典> 中可以实现的体验经验。 开发人员可以将 JavaScript 添加到任何页面、添加页眉和页脚、将菜单项添加到列表和库，以及自定义列表中字段的视图。
开发模型和工具
SharePoint 框架是使用基于 Web 堆栈的新式 TypeScript、JavaScript、HTML 和 CSS 从一开始构建的。 生成的项目的所有部分都在最终用户的浏览器中执行。 SharePoint 框架还附带了一组新的工具。 此新工具与平台无关，适用于 Windows、macOS、Linux，并且基于开源技术，例如 Node.js、 Gulp、 Webpack和 Yeoman。 开发者在生成项时使用这些框架和工具，以简化生成、打包和部署体验；实际执行 SharePoint 框架代码时并不需要这些框架和工具。
SharePoint 框架的当前状态
SharePoint 框架已于 2017 年 2 月发布到 SharePoint Online。 Sharepoint Framework 的最新版本和所有先前版本都在 sharepointonline 中托管并且可用。
SharePoint 框架还适用于版本为 v1.1 的 SharePoint Server 2016（功能包 2），SharePoint Server 2019 版本为 v1.4.1。
开发人员的观点
不管是刚开始接触还是资深的 SharePoint 开发者，都可以从 SharePoint 框架中有所获益。 它允许开发人员以安全且结构化的方式使用客户端组件扩展 SharePoint 的用户界面功能。 这些组件在客户端执行，并且可以使用 SharePoint 中的数据，Microsoft 365通过 Microsoft Graph，甚至使用使用标准 OAuth 和 REST 方法的自定义 Web API。
资深的 SharePoint 开发者应该对 Web 部件和 SharePoint 数据模型等概念非常熟悉。 但是，用于生成、打包和部署客户端 Web 部件的工具将是新的。 开发者尤其需要掌握 TypeScript 技能，这是 SharePoint 框架项的主要开发语言。 除了具有 JavaScript 的好处外，TypeScript 还有其他许多好处，这对企业开发来说非常重要，如强类型对象、对象继承、类和接口，当前的 .NET、Java 和 C/C++ 开发者应该对所有这些概念非常熟悉。 从生成和打包的角度来看，Visual Studio 不再是开发者编写 SharePoint 解决方案的唯一选项；由于使用开放源代码技术以及 node.js、npm 和 Gulp 等项目，开发者可在任意平台上使用首选的代码编辑器或 IDE（例如 Visual Studio Code、Sublime 或 Notepad）进行 SharePoint 框架开发。
对于以前从未构建过 SharePoint 解决方案但熟悉新式 Web 技术的开发人员而言，没有重要的学习曲线。 许多开发人员已迁移到客户端开发或其组合。 客户端开发可为用户提供更动态且响应速度更快的超棒体验，并能为开发者提供更轻松的体验。 由于可自由选择代码编辑器，并能使用常见的知名开放源代码框架和技术，因此许多可能没有接触过 Microsof 生态系统的开发者都可以很轻松地快速生成 SharePoint 扩展插件。
SharePoint Online 扩展的最常见模式之一是使用 JavaScript 嵌入（亦称为“JavaScript 注入”）。 这种方法是指，使用脚本编辑器 Web 部件（举个例子）在页面上插入任意 JavaScript，然后使用 Web 浏览器 DOM（文档对象模型）操作注入 HTML、CSS 和 JavaScript 来生成解决方案或应用程序。 此方法有许多缺点，在许多情况下，甚至禁止客户利用 SharePoint Online 中的新功能，因为它依赖于 SharePoint 如何构建 HTML 和 CSS 结构。 SharePoint 框架对通过 JavaScript 嵌入实现自定义项进行了改进（尽管还无法完全替代）。 如前所述，SharePoint 框架使用 TypeScript，以便用户可以从 JavaScript 嵌入相当容易地切换至不过时的标准化技术。 OfficeDev PnP 计划还提供了有关如何执行这一切换的示例项目和指南。
前景展望：SharePoint 框架在 SharePoint 平台中的应用更广泛
SharePoint 框架是对现有方法进行补充的全新模型，侧重于挖掘用户界面自定义项（如客户端 Web 部件）的更多价值。 此框架旨在与现有模型配合使用，并能让用户按更受支持的可持续化方式更轻松地新建用户界面自定义项。
重要
SharePoint 页面 HTML DOM 不是 API。 应避免对页面 DOM 结构或 CSS 样式采取任何依赖项，它们可能会改变并且可能破坏解决方案。 SharePoint 框架提供了丰富的 API 以通过可靠的方式来自定义 SharePoint 体验，并且是与 SharePoint 页面 HTML DOM 交互的唯一支持方式。
对比外接程序
SharePoint 外接程序在 SharePoint 2013 中作为 SharePoint 应用引入，但之后已重命名，是以受支持且受管理的方式向 SharePoint Online 添加自定义项的唯一可用选项之一。 不过，与只需要添加简单的用户界面自定义项的许多情况相比，SharePoint 外接程序要求使用很多不必要的基础结构。
有两种类型的 SharePoint 外接程序：SharePoint 托管和提供程序托管。 SharePoint 托管的外接程序是以支持的方式在 SharePoint 中执行客户端代码的一种方式，但如前所述，这与仅添加简单的客户端 (JavaScript) Web 部件相比，需要做很多不必要的工作。 在许多情况下，SharePoint 托管的外接程序仅旨在将列表和 Web 部件等项部署到 SharePoint 网站上。 这些外接程序位于名为“应用程序 Web”的“特殊”网站中，这是一个只有部分功能的网站。
提供程序托管的外接程序是从 SharePoint （Online） 远程执行的加载项，可以利用服务器端代码和客户端代码。 这不仅为希望保护知识产权/代码/逻辑的 ISV 带来了福音，为无法使用 JavaScript 在客户端执行的方案（如长时间运行、需要执行大量计算的操作或无法使用客户端脚本实现的远程数据访问）带来了福音。
外接程序的主要优点是能实现隔离：因为实际代码不在 SharePoint 网站浏览器中执行，所以跨网站脚本保护措施可防止外接程序获得和用户拥有的相同访问权限。 外接程序只拥有在安装时授予的权限。 这样一来，如果管理员是从第三方获取外接程序，外接程序就更为安全。此外，Microsoft 还可以提供用于下载外接程序的商店。
SharePoint 框架不仅可与 SharePoint 托管的和提供商托管的外接程序配合使用，还可以在只需要客户端脚本的情况下用作备用模型。 例如，外接程序可以将应用程序部件添加到托管网站。 这些应用程序部件与 Web 部件类似，区别在于它们是在页面 Iframe 内的自己域（应用程序 Web 或提供商托管的 Web）中运行，而不是在页面上下文中运行。 这样一来，可阻止外接程序从页面的其余部分获取用户上下文。
SharePoint 框架不在 Iframe 中运行。 正因为这一点，它可以在页面上下文中更顺畅地运行，同时提供完整功能，方便用户查看部件。 这就是它能够在运行时提供丰富功能的关键所在，但同时也意味着它不具有与外接程序相同的安全控制水平。正因为这一点，SharePoint 框架解决方案也被称为完全信任的客户端解决方案。 Iframe 存在的问题是无法响应，这就导致呈现的网页无法在移动电话或备用尺寸屏幕上这么顺畅地展示。
由于前面提到的安全方面，SharePoint 框架解决方案在编写时没有可在其中下载和安装解决方案的存储。 在许多情况下，使用用户的上下文是一种可改用 SharePoint 框架的所需方案。
在 HTML 中嵌入 JavaScript
开发人员常用的方法之一是使用一种称为嵌入 JavaScript 的方法（也称为 JavaScript 注入）。 也就是说，已使用自定义操作、母版页或页面布局和脚本编辑器 Web 部件等将任意 JavaScript 插入网站和页面。 此方法已证明比创建 SharePoint 托管的外接程序更简单，并允许脚本代码在用户的完整上下文中运行，这就是获得众多热门内容的原因。 这种方法的缺点是，许多嵌入都依赖 DOM 操作，开发者需要掌握一定技能才能运行和维护。
由于 SharePoint Online 的常青特性，嵌入 JavaScript 生成的这些解决方案可能会在更新 SharePoint Online 时中断，因为开发人员可能对 SharePoint 页面的结构或样式进行了依赖（甚至是意外的）。 SharePoint 更新完成后，即使是细微的变化，也可能会对这些解决方案产生巨大影响，并导致嵌入的 JavaScript 完全损坏。
现在有了 SharePoint 框架，就能以 Microsoft 支持的标准化方式实现以前使用 JavaScript 嵌入生成的诸多解决方案。
脚本编辑器 Web 部件
在 SharePoint 中插入任意 HTML、JavaScript 或 CSS 自定义项的最常见方法是使用脚本编辑器 Web 部件或内容编辑器 Web 部件。 脚本编辑器 Web 部件已广受欢迎，因为将自定义脚本添加到任何页面的难易程度。 网站的任何编辑器都可以将脚本编辑器 Web 部件添加到页面、复制 JavaScript 并将其粘贴到其中，并让该 JavaScript 执行必要的自定义。 就像 JavaScript 嵌入一样，对于管理员来说，控制脚本编辑器 Web 部件是一项很有挑战性的任务。
在许多情况下，SharePoint 框架可以直接替代这些脚本编辑器 Web 部件配置。
SharePoint Online 中的脚本功能控制
SharePoint Online 允许管理员控制向网站和页面添加自定义脚本，以提高租户的安全性和完整性。 为此，可以使用 SharePoint Online 管理网站中的“自定义脚本”功能，也可以使用 PowerShell 逐个网站执行。
可在所有网站或仅在个人网站上禁用自定义脚本。 默认情况下，新租户在个人网站上禁用脚本、所有自助服务创建的网站以及租户的根网站集。
禁用自定义脚本时，不允许网站编辑器添加 Web 部件，如脚本编辑器 Web 部件。 不过，SharePoint 框架解决方案可以这样做，因为它们在应用程序目录中经管理员批准后被认为是安全的。
SharePoint 框架解决方案创建方式的不同之处及其非常重要的原因
SharePoint 框架利用新式 Web 堆栈方法，并以基于客户端/浏览器的自定义项为重点，为 SharePoint 开发者提供了一种全新范例来设计、生成和部署 SharePoint 自定义项。
这标志着 SharePoint 开发处理方式的重要转变。
通过使用 TypeScript、Node.js、Yeoman、Gulp 等技术和框架，SharePoint 框架可吸引传统上未使用过 SharePoint 甚至 Microsoft 生态系统的开发人员受众，同时，为现有 SharePoint 开发人员打开了使用更新式和标准化的方法构建 SharePoint 自定义项的门。
创建解决方案
由于需要通过 Visual Studio 提供的特定工具和目标工具，SharePoint 开发是通过基于 Windows 的开发环境中的Visual Studio完成的，该环境具有本地安装和配置的 SharePoint 实例。 这限制了硬件和用户首选项，并增加了开发成本。 另一方面，SharePoint 框架使用适用于许多不同平台（如 macOS 和 Linux）的各种常见开源 Web 工具，以实现更灵活的开发。
SharePoint 框架解决方案是通过结合使用 Yeoman 工具和基于 Node.js 的特定 SharePoint 框架生成器创建而成。 Yeoman 是一款项目基架工具，不仅可以创建项目并生成相应的项，还能安装所需的 Node.js 包并配置生成系统。
生成项目后，可以在任何操作系统（如 Visual Studio、Visual Studio Code、Sublime 或 Atom）上的任何编辑器中对其进行编辑。 这样就可以在团队内部和团队之间协调更多样的用法偏好和风格。 可以对同一项目多次运行 Yeoman 生成器，以添加其他项（如客户端 Web 部件）。
开发和生成解决方案
生成系统基于 Gulp。 Gulp 是一个任务运行程序，可生成、打包和（可选）部署 SharePoint 框架项目。 与 Yeoman 一样，Gulp 也基于 Node.js，以便开发者可以在任意操作系统上生成和部署项。
SharePoint Framework 生成工具集的一部分是 Workbench。 工作台是开发者用来托管和测试 SharePoint 框架解决方案的工具。 工作台具有回应性，它会在开发者保存文件后自动重新加载项，以便开发者能够快速查看和测试解决方案。
Workbench 有两个版本。 SharePoint 外部存在一个版本，该版本本地托管在未访问 SharePoint 和 SharePoint 数据的脱机运行的开发计算机上。 这样，团队和设计人员可以生成和设计包含模拟或虚假数据的解决方案，将重心放在用户界面上。
Workbench 的另一个版本托管在 SharePoint 内，在需要使用真实的 SharePoint 数据和上下文测试和验证 SharePoint 框架解决方案时使用。
重要
本地 Workbench 需要新式常青浏览器。 本地 Workbench 不支持 Internet Explorer 11。
部署 SharePoint 框架解决方案
部署 SharePoint 框架解决方案的方法是将解决方案包部署到应用程序目录，并批准它用于租户或网站集。
对于部署到 SharePoint Online 的解决方案，可以使用Microsoft 365托管 CDN 在用于实现客户端组件的解决方案中存储和处理项目。 有关详细信息，请参阅Microsoft 365公共 CDN部分。
对于部署到 SharePoint Server 的解决方案，需要确定项目存储位置。 这是 SharePoint Online 不需要的其他部署步骤。 唯一的要求是解决方案的用户可以访问项目。
SharePoint Online CDN 的替代项
SharePoint 框架解决方案的开发者可以选择使用任意 CDN 服务（如 Azure 存储、Azure CDN 或 SharePoint 本身），最好使用 SharePoint CDN 功能（请参阅本文档后面的内容）。 使用公用 CDN 可让许多租户使用 SharePoint 框架解决方案，因为部署到 CDN 的资产在 Internet 上公开提供。 在部署了 SharePoint CDN 的 SharePoint 框架解决方案中，部署的脚本和资源只能用于其部署到的租户。
默认情况下，生成工具中有一个内置任务，用于将打包解决方案部署到 Azure Blob 存储。 这通常是由 SI 或 ISV 进行扩展，以支持自定义 CDN 位置或配置。
更改代码并生成解决方案后，SharePoint 框架工具链会生成一个新的解决方案包， (*.sppkg) 和一组脚本文件。 这些脚本文件在其文件名中包含一个唯一的哈希，可表示这些文件的内容与以前部署的版本不同。 若要使用新版解决方案，必须将一组新的脚本部署到 CDN，并更新应用程序目录中的解决方案包。 虽然从理论上讲，可以替换现有脚本文件的内容，并避免升级解决方案包，但这种做法不可靠，因此不建议这样做。 根据 CDN 的配置，可能会将之前下载的脚本文件在客户端计算机上缓存很长时间，从而使向最终用户推广解决方案变得复杂。
CDN 的位置至关重要。 SharePoint 框架资产的托管位置必须具有高可用性，因此建议选择可靠的 CDN 提供商，如 Azure、Akamai 或类似提供商及 SharePoint 本身。 从安全角度来看，了解已部署的 SharePoint 框架解决方案所用的 CDN 至关重要。 损坏的 CDN 也会导致 SharePoint 框架解决方案损坏。在最坏的情况下，遭到入侵的 CDN 可能会导致 SharePoint (Online) 租户中的数据也被盗用。
批准第三方 SharePoint 框架解决方案时，核对清单中通常都会有一项，就是检查 CDN 位置和任何可能托管解决方案的第三方的权限和可信任度。 这是因为在 SharePoint 网站集中安装并使用应用程序后，这些网站集就会依赖 CDN 位置。 在撰写本文时，没有简单的方法来控制该终结点。 CDN 的第三方提供商会在用户不知情的情况下更新需要的和不需要的更改，这会导致解决方案易受到攻击（假定 SharePoint 框架是在用户上下文中运行，并可执行用户完成的任何操作）。
建议 IT 管理员跟踪所用的 CDN 以及经组织批准的 CDN，也应将这些信息传达给企业开发者。
Microsoft 365公共 CDN
Microsoft 365公共 CDN是 Microsoft 365 和 SharePoint Online 中的一项新功能，允许管理员在 CDN 中自动托管静态资产（如 JavaScript 文件、图像和 CSS 样式），以提供更好的性能。 Microsoft 365公共 CDN 是一种异地分布式缓存功能，可将静态资产保留为接近请求它们的最终用户浏览器。
管理员可以在一个或多个文档库上启用Microsoft 365公共 CDN 功能，该功能将用作静态资产的来源。 通过使用 SharePoint Online PowerShell cmdlet 来管理库和 CDN。 文档库中的资产将复制到Microsoft 365 CDN，并通过生成的Microsoft 365公共 CDN URL 以及与文档库关联的 URL 进行访问。 资产的任何更新将在 15 分钟内反映在 CDN 端点上。 文档库中的任何资产都可以通过 CDN 终结点提供给匿名用户。
SharePoint 框架在企业中的应用
SharePoint 是且一直是最成功的企业协作平台之一，其成功的原因之一是扩展性选项，并将其用作应用程序和集成的平台。 SharePoint 框架让 SharePoint 成为更新式的平台，能以支持的标准化方式在 SharePoint 的基础之上生成客户端自定义项，让这一产品变得更加成功。
企业开发者
借助 SharePoint 框架，企业开发者（通常是创建供组织内部使用的应用程序的开发者）能以支持的结构化方式为 SharePoint (Online) 扩展新功能。 SharePoint 框架提供开发框架、生成管道和实际部署，可满足开发人员的一切需求，让开发人员可以在短时间内通过新解决方案和功能覆盖全部网站集，所有这些都是由应用程序目录控制。 在企业应用场景中，也可以完全控制 CDN 位置，无论是 SharePoint 外部还是内部。你可以非常轻松地将修补程序和更新程序部署到整个组织。
在企业内，管理员和开发者应共同制定有关如何部署 SharePoint 框架解决方案的蓝图。 蓝色打印应包含有关首选客户端框架、CDN 位置等的详细信息。
有关详细信息，请参阅 围绕 SharePoint 框架自定义项构建计划部分。
平民开发者
平民开发者使用 SharePoint 已有很长一段时间，他们使用很多方法和技术来生成业务应用程序。
SharePoint 框架适用于特定的应用场景，具体而言 JavaScript 嵌入和脚本编辑器 Web 部件解决方案就是不错的发展方向。 这可以让这些解决方案更加标准化，且可在一段时间内进行维护。 对于公民开发人员来说，可能需要一些学习曲线来适应这种构建解决方案的新结构化方式，但从长期来说，这证明是更加稳定、安全且可维护的。
鉴于上述 自定义脚本 控制方法已到位，不允许公民开发人员添加任意 JavaScript 代码或脚本编辑器 Web 部件。 这可能会让 SharePoint 环境更加稳定且可维护，但同时也可能会限制公司的创新能力，所以应确保平民开发者与企业开发者在今后如何使用 SharePoint 框架方面保持一致做法。
用户体验设计人员和前端开发者
对于 Web 开发人员或用户体验/界面设计人员来说，SharePoint 框架将很有价值。 借助工作台，前端开发者可以在任何操作系统上处理 SharePoint 框架解决方案，并使用自己的首选编辑工具，而不使用 SharePoint（假定他们使用的是模拟数据，并将重心放在用户体验上）。
SharePoint 框架与 Office UI Fabric（Office 和 Microsoft 365 的官方前端开发框架）并行发布，并允许用户体验设计人员跨 Office、Microsoft 365 和自定义生成的解决方案创建无缝体验。
系统集成商 (SI)
如果利用系统集成商 （SI） 或咨询人员来构建 SharePoint 和Microsoft 365解决方案，则应就如何构建 SharePoint 框架解决方案提出建议甚至要求，以便它们与 SharePoint 框架的企业计划保持一致。
系统集成商通常会按首选方式生成解决方案，这可能会与你的治理方式不一致，因此请务必与系统集成商展开讨论，最终会利于各方更轻松地开展工作。
有关系统集成商的典型应用场景是，他们为你的公司生成解决方案，在项目完成后，由你的公司来维护、升级和更新解决方案。仅强调一点，你需要与 SI 在生成和托管 SharePoint 框架解决方案时采用的做法保持一致。
独立软件供应商 (ISV)
独立软件供应商 (ISV) 是生成面向大众市场的第三方解决方案的组织，可能不一定会实现你的 SharePoint 框架解决方案计划。 此外，ISV 通常拥有自己的代码和知识产权，这使得你很难更改其实现和托管解决方案的方式。
使用来自第三方提供商的 SharePoint 框架解决方案时，需要专门考虑它们如何管理更新以及如何托管其解决方案。 例如，是否允许在不知情的情况下更新解决方案？ 是否允许在无法控制的 ISV CDN 上托管静态资产？ 与此 ISV 有何信任关系？
请注意，SharePoint 框架中的所有客户端代码都是在当前用户上下文中执行，无法对此进行约束，但可以在使用 SharePoint 外接程序时这么做。
生成有关 SharePoint 框架自定义项的计划
要将 SharePoint Framework 用作扩展 SharePoint (Online) 实例的工具之一时，需要对此进行规划。 应先规划在生成 SharePoint 框架解决方案时使用的新技术堆栈。 开发者可能需要接受有关如何将 TypeScript 用作 SharePoint 框架代码主要编写语言的培训。
SharePoint 框架开发者可能还需要学习 SharePoint 框架的实际工具链（包括 node.js、npm 和 Gulp），以及如何使用不同的 Gulp 任务来生成、打包和部署解决方案。 官方 SharePoint 框架文档或 SharePoint Github 存储库就是不错的入门资源。
开发者可能希望使组织的一个特定客户端框架或不同的框架标准化。 客户端框架包括但不限于React、Knockout、Angular、Handlebars、jQuery 等。在一个框架上实现标准化具有一些优势，因为这样开发人员就可以生成更多可重用的代码，并在生成和维护解决方案的方式方面具有更好的一致性。
允许多个框架具有优点，因为每个客户端框架都有其优缺点和用例。 不过，允许使用任意客户端框架可能会导致企业解决方案碎片化，更何况使用多个不同的框架还可能会延长页面加载时间，因为使用多个框架需要加载更多的外部库。
开机即用的 SharePoint 框架 Yeoman 生成器提供两个客户端框架的模板：React 和 Knockout。 随着时间的推移，人们可以期望社区添加更多生成器或子生成器来使用其他客户端框架。 选择 React 作为首选客户端框架有好处，因为 Microsoft 已创建 React 版本的 Office UI Fabric，这样便可以让自定义项拥有 Office 和 Office 365 外观（如果组织更倾向这样的外观的话）。
第四点是部署解决方案项目的方式和位置，即所生成的脚本捆绑包和存储资产的 CDN。 在工具链包含的开机即用 Gulp 任务中，仅支持 Azure Blob 存储和 Azure CDN。 如果可以管理 Azure 订阅并在多个租户之间共享资产，这可能是非常不错的选择。 另一个很常见的应用场景是将 SharePoint Online 及其 CDN 功能用作项的主机。 自 SharePoint 框架 v1.4 起，静态资产默认打包到 SharePoint 框架包内。 在应用目录中部署此包时，将从Microsoft 365 CDN（如果已启用）或应用目录 URL 自动托管它们。
最后，开发人员需要考虑应用程序生命周期管理 (ALM) ：管理源代码和版本控制、自动生成、测试和部署等方式。 可以使用最常见的源代码版本控制系统，例如 Git、GitHub 或 Visual Studio Team Systems。
对于持续集成，没有默认工具，可以使用支持 node.js 的首选工具，例如 Visual Studio Team System、Travis CI 或 Jenkins。 使用这些工具，可以自动执行生成和测试过程，如果成功生成并且已获得批准，甚至可以自动将项部署到 CDN 位置，一切都可自动处理，无论是开发者签入代码，还是部署亦或是生产。
SharePoint 框架解决方案的管理功能
部署到租户的所有 SharePoint 框架解决方案都必须获得租户管理员的批准。 这是通过将 SharePoint 框架 包*.sppkg 文件上传到 Apps for SharePoint 库来完成的。 将新的解决方案添加到库中时，管理员得到一个对话框，要求同意批准在租赁中使用的解决方案。 该对话框解释了这是一个没有任何资源限制的完全信任的客户端代码解决方案，并在用户的上下文中执行。 对话框还会显示主要从哪个域获取内容，即 SharePoint 框架脚本的 CDN 位置。 任何 SharePoint 框架应用程序都可以在从 CDN 进行初始加载后从其他位置加载数据。 获得批准后，就可以在任何网站集上启用 SharePoint 框架解决方案。
应用程序目录管理员可随时从应用程序目录中删除解决方案包，具体方法是从“SharePoint 相关应用程序”库中删除解决方案包。 这样一来，就会禁止在所有网站集中使用此解决方案。 还可以通过修改已上载的解决方案包的 Enabled 属性来禁用此解决方案。 这将立即禁用所有网站集中的解决方案;使用客户端 Web 部件的现有页面不会呈现 Web 部件，并且该应用在网站集上不可用，也不可在现有网站集上添加。 删除 SharePoint 框架解决方案时，它不会删除实际客户端解决方案在 SharePoint 或解决方案使用的任何外部数据源中创建的任何数据或信息。
管理员还可以修改应用程序目录中包的其他属性，以增强网站集内解决方案的显眼程度；例如，可以改变图标、类别、说明和特别推荐的状态。
如果需要更新解决方案包（执行新的 SharePoint 框架项或其他包级别更改时需要），则管理员只需将新版本的包上传到库。
租户管理员也可以监视 SharePoint 框架解决方案，就像使用 SharePoint 外接程序一样。在 SharePoint 管理中心的应用下，SharePoint 管理员可以添加 SharePoint 框架解决方案，然后查看特定解决方案有多少安装位置，以用于 SharePoint 外接程序和 SharePoint 框架解决方案。
要在网站集上启用 SharePoint 框架解决方案，网站集管理员必须将其添加到网站集。 可以通过与 SharePoint 外接程序相同的方式完成此操作，即在网站集上选择“添加新应用”，然后从应用列表中选择解决方案。 添加应用后，可在网站集中使用。 网站集管理员还可以从网站集中删除 SharePoint 框架。 为此，进入“网站内容”，然后选择应用上的“删除”。
SharePoint 框架部署范围
构建 SharePoint 框架解决方案时，开发者可以选择其解决方案是否支持租户范围部署，或是否必须在每个网站上单独部署。 解决方案需要在部署到网站之后提供额外资源（如列表）时需要后者。
在构建解决方案的开发者决定解决方案是否支持租户范围部署时，管理员将对如何部署解决方案做出最终决定。 即使解决方案可以部署到租户中的所有站点，管理员也可以选择仅将其部署到特定站点。 如果解决方案不支持租户范围部署，管理员仅可以将其部署到特定的网站。
重要
租户范围部署仅在 SharePoint Online 中可用。 在本地托管的 SharePoint 中，SharePoint 框架解决方案只能部署到特定的网站。
SharePoint 框架没有 SharePoint 外接程序具有的存储区。 因此，租户管理员始终必须通过向应用目录添加和批准解决方案包来启动任何部署。
备份和还原 SharePoint 框架组件
SharePoint 框架解决方案没有任何特定的备份和还原功能。 从管理角度来看，建议的唯一做法是，如果错误地从应用目录中删除解决方案包，最好将所有已安装的解决方案包文件的副本 (*.sppkg) 。 不过，应用程序目录是 SharePoint 库，功能与任何文档库相同，已启用主要版本控制和回收站。
无法备份的是实际解决方案项目，如在 CDN 中托管的脚本捆绑包和资产。 如果你控制 CDN 或 CDN 是 SharePoint 网站，则可以备份它们。 如果使用第三方提供的 SharePoint 框架解决方案，则组织可能无法备份它们。
SharePoint 框架路线图
在 2017 年 2 月，SharePoint 框架就已进入通用版本 (GA)。 通用版本表示 IT 和开发人员可通过受支持的方式在生产中使用 SharePoint 框架。 除了通用版本之外，我们还将扩大有关 SharePoint 框架组件生成和使用的一系列应用场景，不仅支持 Web 部件应用场景，还支持列表和网站自定义项等。
有关 SharePoint 框架的详细信息，请参阅专门的 SharePoint 框架路线图文章。
重大更改或引入主要新功能将通过 Office 365 消息中心发布，可在租户管理中心内了解相关信息（Office 365 管理员应已养成每天例行查看租户管理中心的习惯）。 另一重要资源是 Office 开发者博客，其中介绍了更多详细信息和更新。
支持和 SLA
Microsoft 不通过常规 SharePoint Online 支持通道为针对 SharePoint 生成的自定义解决方案提供支持。 与生成 SharePoint 解决方案相关的所有问题都应记录在 https://github.com/SharePoint/sp-dev-docs/issues 的 GitHub 上。 SharePoint 工程组定期对此存储库中的问题进行分类，并尽力尽快响应传入请求。
如果你的组织具有顶级支持协议，那么它应该是请求任何与生成 SharePoint 解决方案相关问题支持的默认通道。 Microsoft 呈报工程师将根据其紧急程度处理请求。
SharePoint 框架设计为后向兼容。 在提前给出特定版本的明确弃用通知之前，Microsoft 保证使用任何公开发布的 SharePoint 框架版本生成的解决方案将继续有效。
摘要
SharePoint 框架是 SharePoint 自定义工具箱新增的超棒演变模型，允许开发人员以支持的可控方式扩展 SharePoint。 SharePoint 框架基于开放源代码和新式技术，不仅支持由 SharePoint 团队进行 SharePoint 企业开发，还可以由一组不同的开发者进行。 作为管理员，在租户内为 SharePoint 框架 提供适当的治理和支持，可让开发人员更快地生成更具吸引力的解决方案，从而全面提高效率。
由于 SharePoint 框架面向第一方和第三方开发者，并且 Microsoft 越来越多地将其用于今后开发 SharePoint 增强功能，因此也是可供组织采纳的稳妥做法。 随着时间的推移，我们将对 SharePoint 框架执行增量更新和内容添加，以缩小经典 SharePoint 和新式 SharePoint 功能体验之间的差距。