Lightning Experience 带来了全新的 UI，但这不意味着你的 Visualforce 应用会停止工作。本篇是 Trailhead「Visualforce & Lightning Experience」模块的中文导读，讲解 Visualforce 页面在全新 Lightning Experience 中如何运行、如何适配：从页面可以出现在哪里、如何开发测试，到页面在 Lightning 容器（iframe）里的运行差异、安全与作用域、导航规则、样式策略，以及需要避免的功能。
全文分七个单元：第一单元认识 Lightning Experience 中 Visualforce 的使用位置；第二单元了解开发、查看和测试页面的正确方法；第三单元深入 Lightning 容器（iframe）；第四单元让页面在 Classic 与 Lightning 之间共享；第五单元管理导航；第六单元理解样式与 Lightning Design System；第七单元识别需要避免的功能。每个小节对应一页 PPT 幻灯片并附讲解视频。
01 在 Lightning Experience 中使用 Visualforce（Use Visualforce in Lightning Experience）
本单元认识 Visualforce 在 Lightning Experience 中的使用。学完本单元，你将能够：识别使用前需考虑的两个高层要点，并列出至少五个可以使用 Visualforce 的位置。
在 Lightning Experience 中使用 Visualforce（Use Visualforce in Lightning Experience）
Visualforce 页面在 Lightning Experience 中可以使用，许多甚至无需任何修改。四个要点：
- Visualforce「开箱即用」——页面在 Classic 和 Lightning Experience 中都正常工作。
- 使用内置标准组件的页面保持 Salesforce Classic 外观，除非你重新设计样式。
- 使用 JavaScript 的页面需要检查——在 Lightning Experience 中 Visualforce 不再拥有整个页面。
- 一些运行时细节发生了变化，需要留意。
是的，有些东西移动了位置。接下来快速浏览 Visualforce 在新环境中的位置。
Lightning Experience 中可使用 Visualforce 的位置（Where You Can Use Visualforce）
与 Classic 一样，你可以用自定义 Visualforce 页面和应用扩展 Lightning Experience，但找到它们的位置变了，仍有一些地方无法承载 Visualforce。快速浏览：
- App Launcher / 导航栏
- 标准页面布局内部
- Lightning App Builder 中的组件
- 快速操作
- 覆盖按钮或链接
- 自定义按钮和链接
从应用启动器打开 Visualforce 页面（Open a Visualforce Page from the App Launcher）
你的 Visualforce 应用和自定义选项卡都可以从应用启动器（App Launcher）访问：点击导航栏中的 App Launcher，选择 View All 查看所有应用和项目，点击一个自定义应用激活它——其项目（包括你添加的 Visualforce 选项卡）显示在导航栏中。你需要把 Visualforce 页面添加到选项卡中才能出现在 App Launcher 里；不在任何应用中的选项卡可在 All Items 下找到。
把 Visualforce 页面添加到导航栏（Add a Visualforce Page to the Navigation Bar）
把 Visualforce 选项卡添加到一个应用后，它们就作为项目显示在该应用的导航栏中，让用户一键访问你的页面。（顺便一提——"ForceUI" 工具页面听起来有趣吗？继续往下读本模块！）
在标准页面布局中显示 Visualforce 页面（Display within a Standard Page Layout）
通过把 Visualforce 页面嵌入页面布局，在标准页面上显示完全自定义的内容。行为与 Salesforce Classic 相同，只是在 Lightning Experience 中需要查看记录的 Details 才能看到页面布局。
在 Lightning App Builder 中添加 Visualforce 页面组件（Add as Component in the Lightning App Builder）
在 Lightning App Builder 中创建自定义应用页面时，可以用 Visualforce 组件添加 Visualforce 页面。要求：在 Visualforce 页面上启用 「Available for Lightning Experience, Lightning Communities, and the mobile app」。
把 Visualforce 页面作为快速操作启动（Launch a Visualforce Page as a Quick Action）
可以把 Visualforce 页面作为快速操作启动。它在 Lightning Experience 中的位置与 Classic 差异很大，但添加过程基本相同——加到对象页面布局上合适的发布区域。
通过覆盖标准按钮或链接显示 Visualforce 页面（Override Standard Buttons or Links）
可以用 Visualforce 页面覆盖对象上的动作：用户点击被覆盖的按钮或链接时显示你的页面。设置几乎与 Classic 相同——定义动作覆盖时，你几乎察觉不到自己身处 Lightning Experience。
使用自定义按钮或链接显示 Visualforce 页面（Using Custom Buttons or Links）
可以为对象创建新动作（按钮和链接）。JavaScript 按钮和链接在 Lightning Experience 中不受支持，但 Visualforce（和 URL）项目受支持。定义过程与 Classic 相同。
02 为 Lightning Experience 开发 Visualforce 页面（Develop Visualforce Pages for Agentforce 360 Platform）
本单元设置开发环境并学习测试方法。学完本单元，你将能够：设置编辑环境、了解两种在开发期间查看页面的方式，并区分非正式预览与正式测试（含测试矩阵）。
为 Lightning Experience 开发 Visualforce 页面（Developing Visualforce Pages）
为 Lightning Experience 开发与为 Classic 开发在某些方面大不相同，在另一些方面则相同。主要区别在于开发期间如何查看和测试页面。好消息是：Lightning Experience 的流程与你开发 Salesforce 移动页面时使用的相同。本单元涵盖环境设置和构建时"正确"的测试方式。
设置你的编辑器（Set Up Your Editor）
设置编辑工具的过程在面向 Lightning Experience、Classic 还是 Salesforce 应用时都相同：开发者控制台、Setup 编辑器、原生工具（VS Code Salesforce Extensions 等）都不变。唯一的例外是 Development Mode 页脚：Visualforce 的 Development Mode 只在 Salesforce Classic 中可用——在 Lightning Experience 通过 /apex/PageName 访问页面会被带回 Classic。
开发期间查看 Visualforce 页面（一）：直接 URL 的陷阱（The Direct-URL Trap）
检查进度的常见方式是直接 URL 访问 https://yourInstance.salesforce.com/apex/PageName。但在 Lightning Experience 中有个问题：这样查看的页面总是以 Salesforce Classic 显示（无论你的 UI 设置如何），无法审核 Lightning 特定行为。原因：/apex 和 /lightning 是两个不重叠的 URL，要看到 Lightning 行为必须在 /lightning 内运行。
开发期间查看 Visualforce 页面（二）：进入 Lightning（Get Inside Lightning）
要查看 Lightning 特定行为，必须从 Lightning Experience 应用内部查看页面：
- 简单路径：为页面创建选项卡（Tabs Setup），通过 All Items 导航到它。
- 长期方案：创建一个「In Development」自定义 Lightning 应用（Setup → App Manager → New Lightning App，限制给管理员/开发者），保持可见，创建仅开发者可见的 Visualforce 选项卡加入该应用。
- 低开销技巧：在 Lightning Experience 的 JS 控制台触发
navigateToURL事件（在 Classic 会失败）。
在多个环境中审核 Visualforce 页面（Reviewing in Multiple Environments）
跨 Classic、Lightning Experience 和 Salesforce 应用使用的页面必须在所有这些环境中审核。切换环境选择器很快会让人厌烦，浏览器 user-agent 技巧更繁琐。更好的做法是用多个浏览器/设备 + 至少一个额外测试用户：
- 主开发环境：Chrome + 开发者用户 + Classic。
- Lightning 审核：Safari/Firefox + 测试用户 + Lightning Experience。
- 移动审核：真实 iOS/Android 设备 + Salesforce 应用 + 测试用户。
关键是两个不同浏览器让你同时访问 Classic 和 Lightning，用真实设备测试应用。
测试你的 Visualforce 页面（Testing Your Visualforce Pages）
上线前的正式测试必不可少，而 Lightning Experience 让测试更复杂。构建一个测试矩阵覆盖：每种支持的设备、每种操作系统、每种浏览器（含 Salesforce 应用内嵌浏览器）、每种 UI 上下文（Lightning、Classic、Salesforce 应用）。有些因素会合并（如 iPhone + iOS + 应用 = 一个组合）。尽早测试、经常测试、测试一切！
03 探索 Visualforce 应用容器（Explore the Visualforce App Container）
本单元学习 Lightning 容器。学完本单元，你将理解 Visualforce 在 Classic 与 Lightning Experience 中最大的区别——容器：在 Lightning 中页面运行在一个 iframe 里，包在 Lightning Experience 单页应用内。
探索 Visualforce 应用容器（Exploring the Visualforce App Container）
最大的区别是环境：在 Salesforce Classic 中，Visualforce「拥有」页面、请求和环境——Visualforce 就是应用容器；而在 Lightning Experience 中，Visualforce 运行在一个 iframe 里，包在更大的 Lightning Experience 容器内。影响程度高度依赖你的代码——Salesforce 努力让大多数页面"开箱即用"，所以多数页面几乎察觉不到。
外层 Lightning Experience 容器（The Outer Container）
Lightning Experience 是一个在 /lightning 访问的单页应用（SPA），类似 AngularJS 或 React。关键点：Lightning Experience 负责请求，你的页面不负责；你的页面在 Lightning 施加的约束（如框架大小）和浏览器施加的约束（安全/JavaScript 规则）下工作。Lightning 是父上下文，你的页面是子上下文。
Visualforce iframe（The Visualforce iframe）
在 Lightning Experience 中，你的页面显示在一个 HTML iframe 里——一个嵌入的浏览上下文，与主 Lightning 上下文相对独立，在你页面和父级之间形成边界。这解释了为什么很多页面"开箱即用"：不需要访问顶层上下文的页面看起来几乎与 Classic 相同。反过来，需要顶层上下文的页面则需要修改；与 Salesforce 之外的服务通信时，可能还要更新 CORS、远程站点、clickjack 或 CSP 设置。
新容器的影响（Impact of the New Container）
把页面嵌入 Lightning 应用里的 iframe 会带来两大类影响：
- 安全（Security）：会话维护与续期、认证、跨域请求、嵌入限制。
- 作用域（Scope）：DOM 访问与修改、JavaScript 作用域与访问、
window.location等全局变量。
好消息是大多数页面不受影响——但了解这些分类能让你在问题出现时更快定位。
安全影响（Security Impact）
需要关注的安全事项：
- 跨域请求：来自不同服务器的内容可能在未准备好的上下文中拒绝显示，需要为 Lightning Experience 上下文准备好这些服务。
- 会话维护：
$Api.Session_ID按域返回不同值（.salesforce.com与.force.com），Lightning 和你的页面由不同域提供，iframe 内的会话 ID 与外部不同。Salesforce 通常透明处理——除非你自己在传递会话 ID。
作用域影响（Scope Impact）
作用域指 DOM 和 JavaScript 的可见性。规则：不要碰别人的东西——你的 JS（和 CSS）只能影响你自己页面浏览上下文中的元素，不能访问其他上下文（如父 Lightning 上下文）。最常见的出错是设置 window.location（你的 iframe 不拥有顶层 window 位置）。不要用 contentWindow/window.parent 绕过（会撞上同源策略），而应使用 Salesforce 提供的导航 API，跨框架用 window.postMessage。
Lightning Experience 中 Visualforce 的默认值和环境变化（Defaults and Environment Changes）
页面在 Lightning Experience 中运行时，后台会发生若干低层变化，正是它们让大多数页面在容器中"开箱即用"。有些变化显而易见（如 Classic 页头和侧边栏始终被抑制），另一些不太可见但同样重要——在构建高级应用流程或排查疑难问题时，你需要知道它们。
showHeader 和 sidebar 属性始终为 false（Always false）
showHeader 和 sidebar 控制 Classic 页头/侧边栏。在 Lightning Experience 中它们总是被抑制（为 Lightning Experience 导航元素让位），且没有对应属性可抑制 Lightning 页头或侧边栏。如果页面与 Classic 共享，你仍可设置这些属性供 Classic 使用。注意 standardStylesheets 不受影响，默认 true，但你可以更改。
sforce.one JavaScript 工具对象（The sforce.one JavaScript Utility Object）
sforce.one（不是机器人！）是一个 JavaScript 工具对象，提供若干有用函数。它在页面运行于 Lightning Experience 或 Salesforce 应用时自动注入（无需添加、也无法抑制），在 Salesforce Classic 中不可用。主要用途是触发导航事件，详见「管理导航」单元。
04 在 Classic 与 Lightning Experience 之间共享 Visualforce 页面（Share Visualforce Pages Between Classic and Lightning Experience）
本单元学习检测并响应 UI 上下文。学完本单元，你将能够：构建在 Classic 和 Lightning Experience 中都正确行为的页面，并用标记、JavaScript 和 Apex 检测当前运行的 UX。
共享 Visualforce 页面（Sharing Visualforce Pages）
尽可能创建在 Classic 和 Lightning Experience 中都正确行为的页面——这能降低代码和配置复杂度，有些上下文你别无选择（如动作覆盖在所有 UI 中都用同一页面）。不过按上下文提供不同行为或样式也合理。本单元展示检测当前 UX 并适配的多种方式。
在 Visualforce 标记中检测并响应 UX 上下文（一）：主题全局变量（Theme Globals）
用 $User.UITheme 和 $User.UIThemeDisplayed 判断当前 UX 上下文，两者返回相同的主题值集合：Theme4d=Lightning Experience、Theme4t=Salesforce 应用、Theme2/Theme3=Classic 主题等。区别：UITheme 返回用户"应该"看到的界面，UIThemeDisplayed 返回用户"实际"看到的界面。规则：代码中用 UIThemeDisplayed。
在 Visualforce 标记中检测并响应 UX 上下文（二）：应用它（Apply It）
在布尔表达式中使用主题测试：{! $User.UIThemeDisplayed == "Theme3" }，放在组件的 rendered 属性上按上下文显示/隐藏。更高效的模式：用 <apex:outputPanel> 包住大块内容，在块的 rendered 上测试一次主题。动态样式表：apex:stylesheet 没有 rendered 属性，用 <apex:variable> 包裹借用其 rendered（该变量实际不会被创建）。
在 JavaScript 中检测并响应 UX 上下文（Detecting in JavaScript）
重度使用 JavaScript 时（尤其是选择正确的导航技术），用 UITheme.getUITheme() 全局变量检测当前 UI 主题，据此分支——例如若当前是 Lightning Experience 主题就使用 Lightning 导航 API。
在 Apex 中确定 UX 上下文（Determining in Apex）
在 Apex 中用 UserInfo.getUiTheme() 和 UserInfo.getUiThemeDisplayed()，当控制器动作方法或属性需按上下文不同行为时使用（常通过 getter 暴露）。它们返回与 $User 主题全局变量相同的值。最佳实践：服务端使用应很少，让控制器对 UI 上下文保持中立，由前端代码（标记/JavaScript）处理差异。
通过 SOQL 和 API 查询 Lightning Experience（Querying via SOQL and API）
你可以用 SOQL 查询用户偏好的 UX，但不推荐：结果是一个需要转换的原始偏好值，且它告诉你的是用户的偏好设置，而非实际屏幕上的 UX（两者可能不匹配）。要确定当前请求中实际交付的 UX，用 $User.UIThemeDisplayed 或 UserInfo.getUiThemeDisplayed()。
05 管理导航（Manage Navigation）
本单元学习导航。学完本单元，你将能够：了解三种经典的 Visualforce 导航机制（仍然有效），以及现代方式——通过 sforce.one 对象在 JavaScript 中触发导航事件，并避开常见陷阱。
管理导航（Managing Navigation）
导航是应用设计的核心。Visualforce 提供多种添加导航的方式，Lightning Experience 又加入了自己的流程、元素和机制。好消息：经典 Visualforce 导航仍然有效，页面也可使用新的 Lightning Experience 机制。导航有两层含义：用户点击的 UI 元素，以及你自己代码决定用户去向的逻辑。
Lightning Experience 中的导航（Navigation in Lightning Experience）
「导航」的含义：一是 UI 元素（点击菜单、New、快速操作）；二是幕后"发生什么"的逻辑（多数内置，部分可自定义如动作覆盖）；三是你自己应用中的导航——你的代码控制用户动作后的去向，本单元聚焦于此。
经典 Visualforce 导航（Classic Visualforce Navigation）
经典 Visualforce 导航归结为动作方法结束时发生什么：动作方法返回一个 PageReference 对象（含去向），Visualforce 框架把正确响应发回浏览器。好消息是这些仍然有效——标准控制器也从其动作返回 PageReference，所以现有导航（标准或自定义控制器）都继续工作。
现代 Visualforce 导航（Modern Visualforce Navigation）
为什么要谈这个？一个词：JavaScript。随着应用采用 Remote Objects 和 remoting，更多行为迁移到浏览器（那里没有 PageReference）。Lightning Experience 通过 sforce.one 对象用事件管理导航，其函数包括：back()、navigateToSObject()、navigateToURL()、navigateToFeed()、navigateToRelatedList()、navigateToList()、createRecord()、editRecord()。重要：sforce.one 在 Classic 中不可用，使用前须检测其存在。
导航陷阱及修复（Navigation Gotchas）
JavaScript 导航的第一条规则：不要直接设置 window.location。第二条规则：不要直接设置 window.location。细节在接下来的小节展开。
不要直接设置 window.location（Don't Set window.location Directly）
在 Lightning Experience 中，你的页面没有可设置的 window.location——因为页面在 Lightning 单页应用内的 iframe 里，无法访问顶层 window.location，任何设置它的导航代码都会失效。虽有变通方法但不要用：绕过 sforce.one 意味着导航不被记录在 Lightning 导航栈中（该栈支撑 Back 按钮等特性）。
Salesforce Classic 的问题（The Salesforce Classic Issue）
sforce.one 在 Classic 中不可用，那里必须用 window.location（好在 Classic 中 window.location 可用）。代价是代码里要加一个 if 块：if (sforce.one) { ... } else { ... }。建议把导航调用包装成工具方法，让主逻辑保持整洁。
静态 URL（Static URLs）
不要用静态 URL 访问 Salesforce 资源。例如"编辑联系人"链接不要拼 '/' + accountId + '/e'——它只在某些上下文有效。改为：Visualforce 标记里用 {! URLFOR($Action.Contact.Edit, recordId) }，JavaScript 里用 sforce.one.navigateToSObject(recordId)。
06 理解重要的视觉设计考量（Understand Important Visual Design Considerations）
本单元学习样式与 SLDS。学完本单元，你将理解：Visualforce 页面为何保持 Classic 外观、可用的重样式工具，以及匹配 Lightning Experience 的推荐策略，最终落到 Lightning Design System。
理解重要的视觉设计考量（Visual Design Considerations）
Visualforce 页面在 Classic 和 Lightning Experience 中看起来相同（除非你重新设计）：内置组件生成的 HTML 不变，它们使用的 Classic 样式表默认加载。所以使用 inputField、outputField、pageBlock 等的页面仍保持 Classic 外观——Lightning Experience 中间夹着一小块 Classic。对已有页面的建议：暂时别追 Lightning Experience 样式（它还在演进）。对新页面，有很好的工具让它们完美契合。
影响标准组件的样式（Affecting the Styling of Standard Components）
Visualforce 提供多种调整或覆盖标准组件样式的选项，适合做适度的外观改动，工作量也适度。可用工具：style/styleClass 透传属性、自定义样式表（静态资源 + apex:stylesheet）、以及 Salesforce Lightning Design System。
为单个组件设置样式（Styling Individual Components）
生成 HTML 的组件有透传的 style 和 styleClass 属性：style 直接在组件上设置样式，styleClass 挂载别处定义的类。例如 <apex:outputText value="Aside text" styleClass="asideText" style="color:#333;" />。
添加自定义样式表（Adding a Custom Stylesheet）
用静态资源 + apex:stylesheet 给页面添加样式表。独立资源 AppStylesheet：<apex:stylesheet value="{!$Resource.AppStylesheet}" />；压缩资源 AppStyles 内的文件：<apex:stylesheet value="{!URLFOR($Resource.AppStyles, 'app-styles.css')}" />。这是推荐方式（跨页面共享、减少标记）。例外：Lightning Design System 更简单——直接 <apex:slds />。
Lightning Experience 中的不同样式（Different Styles in Lightning Experience）
要让页面仅在 Lightning Experience 中加载自定义样式表，结合「共享」单元的主题检测技术，只在 Lightning Experience 上下文显示 Lightning 样式表——这样单页即可按上下文提供不同样式。
样式策略与建议（Styling Strategies and Recommendations）
要匹配 Lightning Experience 视觉设计，用 Lightning Design System 创建新页面。对已有页面有两种调整方式：改标记或改样式规则（可单独或组合）。唯一受支持的方法是 Lightning Design System 样式表 + 全新标记（用 apex:slds 或下载样式表）。不推荐：把 SLDS 样式硬套到内置组件 HTML 上（阻抗不匹配）、覆盖 Classic 样式表内部（该 HTML 可能变化）。
Salesforce Lightning Design System（The Salesforce Lightning Design System）
SLDS 是一个面向企业应用、外观像 Lightning Experience 的设计框架，包含复杂的 CSS 框架、图形资源和 Salesforce Sans 字体，让你构建与 Lightning Experience 完美匹配的页面（也支持品牌自定义）。关键事实：SLDS 假定全新的标记结构和样式类，最适合新页面和应用；对已有页面改造对大多数组织颇具挑战。
07 了解 Lightning Experience 中要避免的功能（Know Which Features to Avoid in Lightning Experience）
本单元识别要避免的功能。学完本单元，你将了解：Lightning Experience 中建议避免的少量组件、行为不同的功能，以及少数无法承载 Visualforce（或不能如预期工作）的位置。
了解要避免的功能（Knowing Which Features to Avoid）
在 Lightning Experience 中使用的页面，建议避免的组件数量有限。此外，一些功能行为不同，少数位置无法承载 Visualforce 或不能如预期工作。Lightning Experience 仍在演进，Salesforce 希望随时间缩小这个清单。
无法抑制 Lightning Experience 页头和导航菜单（Header Can't Be Suppressed）
Visualforce 页面在 Lightning Experience 中运行时总是显示标准 Lightning Experience UI：无法抑制或更改 Lightning Experience 的页头或侧边栏，showHeader 和 sidebar 在 Lightning Experience 中无效。这是有意为之——在 Lightning Experience 中显示的应用就是 Lightning Experience 应用。如需完全自定义界面，在 Salesforce Classic 中运行。
Classic 页头和侧边栏始终被抑制（Classic Header/Sidebar Always Suppressed）
对于在 Lightning Experience 中显示的页面，Classic 页头和侧边栏始终被抑制：showHeader 和 sidebar 无效，页面表现得像两者都设为 false。standardStylesheets 不受影响（默认 true，但可改）。
Lightning Experience 中被屏蔽的相关列表（Blocklisted Related Lists）
一些相关列表在 Lightning Experience 中不受支持——它们被屏蔽（blocklisted），即被明确禁止使用，apex:relatedList 中同样被屏蔽。可在在线帮助「Data Access and Views: What's Different or Not Available in Lightning Experience」中查看受影响列表。
避免使用 apex:iframe（Avoid Using apex:iframe）
在 Lightning Experience 中并非不能使用 apex:iframe，但建议避免：你的 Visualforce 页面已经被包在一个 iframe 里，再加一层会增加复杂度；嵌套 iframe 很难调试。所以在 Lightning Experience 使用的页面上，避免这个标签。
真的不要直接设置 window.location（No, Really）
再强调一遍：如果页面 JavaScript 直接设置 window.location，在 Lightning Experience 中会失效——因为页面在 iframe 里，无法设置顶层 window 位置。必须修改这些代码。详见「管理导航」单元。
sforce.one 不只是 Salesforce 移动端专用（sforce.one Isn't Mobile-Only）
sforce.one 在 Salesforce 应用和 Lightning Experience 中都可用。如果你一直用 sforce.one 的存在来判断"移动 vs 桌面"，需要更新代码：用文档化的方法（Visualforce、Apex、JavaScript 中都有）区分 Classic、Salesforce 应用和 Lightning Experience。详见「共享」单元。
动作覆盖的变化（一）：对象列表问题（Action Overrides: The Object List Problem）
标准动作覆盖在 Lightning Experience 中行为不同，对象列表（object list）动作的覆盖在 Lightning Experience 中无法访问。在 Classic 中可覆盖六个标准动作（对象选项卡、对象列表、记录查看/编辑/创建/删除）；在 Lightning Experience 中前两者合并为对象主页，覆盖对象选项卡会覆盖对象主页，但对象列表在 UI 中不可达，其覆盖无法触发。若该覆盖承载关键功能，需另寻途径。
动作覆盖的变化（二）：什么在何处触发（Action Overrides: What Fires Where）
覆盖在不同 UX 中的映射：Tab → Classic 是对象选项卡、Lightning 是对象主页、应用是搜索；List → Classic 是对象列表、Lightning 是 n/a（覆盖不可达）、应用是对象主页；View/Edit/New/Delete → Classic 和 Lightning/应用一致（记录查看/编辑/创建/删除）。注意 n/a 不是无法访问标准行为，而是该覆盖的功能不可用。