Azure Stack Hub 计算服务：从架构组件到虚拟机类型与存储模型（上篇）

未经同意，请勿转载！

本篇定位 ：面向 Azure Stack Hub 管理员、云架构师、准备上手 IaaS 资源交付的运维工程师。以 架构组件 → 虚拟机类型 → 部署体验 → 托管磁盘 / 临时磁盘 为主线，把"计算"这条主线在 Azure Stack Hub 上的实现路径从底向上拆解清楚；下篇进入 管理与运维 维度------基础架构 VM 生命周期、配额与容量公式、添加节点、市场镜像同步。

版本基础 ：本文基于 Azure Stack Hub 早期 GA（1910 前后）公开介绍材料的工程化整理，混合当版本（2406 / 2503 等）Azure Stack Hub 多代演进的视角撰写。本文对早期版本与当前版本之间的差异做了显式标注 ，目的是"从历史维度讲清楚计算这条主线的设计初衷与演进"，而不是逐个版本对齐字段。 门户默认值、可用 cmdlet、容量上限、镜像格式在不同 OEM 集成系统（Dell / HPE / Lenovo 等）和不同版本之间可能存在差异 ；当版本与本文描述不一致时，以当版本 Azure Stack Hub Operator 文档为准。

修订说明（v1.0，2026-07-26）

本篇为 新章首发，基于作者的 Azure Stack Hub 计算服务介绍资料整理，并按当前（2026-07）写作准则做工程化改写。

修订类型	关键变更
历史视角显式标注	全文明确标注"基于早期 GA 介绍材料整理"，区分"原始设计目标"与"当前版本实现"。
四层原则落地	区分 L0 版本事实 / L1 微软硬要求 / L2 OEM 实现 / L3 最佳实践，对 VM 类型、存储性能、磁盘行为等做分层标注。
避免硬要求措辞	早期材料中"必须 / 不能 / 必须相同"等绝对化措辞按当前准则降级为"建议 / 通常 / 取决于"。
量化数字审慎	移除所有未能交叉验证的百分比 / 性能倍数 / 镜像大小数字；保留的"30-127 GB"类数字标注"以当版本市场镜像清单为准"。
Image Reference 标注	显式标注 "Visual Studio Community 2015 with Microsoft Azure SDK 2.9.6" 是历史时期参考，当前主流推荐使用 Az PowerShell + ARM/Bicep/Terraform。
托管磁盘 vs Azure 公有云	明确说明"Azure 存储账户限制在 Azure Stack Hub 上不适用"是早期实施层面的描述，当前版本可访问性以 Operator 文档为准。
临时磁盘（D 盘）行为	强调"Windows 页面文件保存在临时磁盘"是微软推荐配置，但是否调整页面文件位置由租户管理员决定。
公开术语原则	全文使用"四层技术事实分类"等通用术语，不引用内部累计的写作准则。

为什么把"计算"拎出来单独讲
[Azure Stack Hub 计算架构：ARM / Hyper-V / 网络 / 存储四层基础](#Azure Stack Hub 计算架构：ARM / Hyper-V / 网络 / 存储四层基础)
[Azure Stack Hub 虚拟机类型：入门级 / 通用型 / 计算密集型](#Azure Stack Hub 虚拟机类型：入门级 / 通用型 / 计算密集型)
[Azure Stack Hub 计算性能：从仿真模型到实测特征](#Azure Stack Hub 计算性能：从仿真模型到实测特征)
[一致的部署体验：GitHub 模板 / PowerShell / Visual Studio](#一致的部署体验：GitHub 模板 / PowerShell / Visual Studio)
托管磁盘：把存储账户与伸缩限制藏起来
[临时磁盘：被仿真为 VM 大小一部分的 D 盘](#临时磁盘：被仿真为 VM 大小一部分的 D 盘)
上篇小结

1. 为什么把"计算"拎出来单独讲

Azure Stack Hub 的"计算"是一个 被低估 的子系统。

对很多刚接触 Azure Stack Hub 的工程师来说，"计算"似乎就是"创建虚拟机"------把它等同于本地 Hyper-V 上的"新建 VM"。但真正把 Azure Stack Hub 用起来的人会很快发现：

Azure Stack Hub 的"计算"不是一个孤立的 Hyper-V 集群 ，而是由 Azure Resource Manager（ARM）控制面 + Hyper-V 集群 + 网络 SDN + 存储空间直通（S2D） 四个子系统协同支撑的"云服务资源"；
"虚拟机"也不只是一个 vhdx 文件 ，而是被 配额（Quota）→ 计划（Plan）→ 套餐（Offer）→ 订阅（Subscription） 围绕承载的治理对象；
"性能"不是简单的核数 × 主频 ，而是要在 物理基础设施 + 资源控制器（CRP）+ 放置规则 三层都做权衡。

因此，理解 Azure Stack Hub 的计算，是理解"如何把一堆裸金属服务器变成可治理的云服务"的最直接路径。本篇先讲 架构、虚拟机类型、部署体验、存储模型 ；下篇讲 基础架构 VM 生命周期、配额与容量、扩容、市场镜像。

概念关系 ：本篇讨论的"计算"是 IaaS 视角下的 VM 服务 ；PaaS 视角下的计算 （如 App Service、Kubernetes Service、Container Registry 等）属于 Azure Stack Hub 上的 Resource Provider 范畴，与本文主线相切，不展开。

2. Azure Stack Hub 计算架构：ARM / Hyper-V / 网络 / 存储四层基础

Azure Stack Hub 的"计算"能力由 四个相互依赖的子系统 共同支撑：

2.1 ARM：控制面入口

ARM 是 Azure Stack Hub 的 统一资源管理层。所有租户操作（创建 VM、配置网络、申请存储）都通过 ARM API 进入，由 ARM 鉴权并路由到对应的 Resource Provider。

租户侧：通过 User Portal / PowerShell / CLI / SDK / REST API 调用 ARM。
管理员侧：通过 Administrator Portal / PowerShell / Admin ARM API 调用，维护 Quota / Plan / Offer / Subscription 等 Operator 层对象。
重要边界 ：Azure Stack Hub 不提供 Azure 公有云的 Subscription 商业模型 （EA / PAYG / MCA），Subscription 是 Operator 自管理的本地治理边界。

2.2 Hyper-V 群集：实际的虚拟机承载层

Azure Stack Hub 的所有虚拟机------包括租户 VM 和 Operator 内部的基础架构 VM------都运行在 Hyper-V 之上。Scale Unit 内的物理服务器统一加入一个 Hyper-V 故障转移群集。

租户 VM 由 Compute RP（CRP）管理生命周期；
基础架构 VM（如 ACS、CRP、NRP、SRP、ERP、Portal、Backup 等）由系统内部管理 ，租户不可见。

2.3 网络：SDN + BGP + ToR

租户 VM 的网络由 Network RP（NRP） 管控，底层是 Azure Stack Hub 的 SDN fabric：

租户 VNet 通过 NVGRE 封装隔离；
边界通过 BGP 把租户 VNet 路由发布到 ToR 交换机；
公共 IP 通过 PIP Pool 分配。

Operator 边界 ：Azure Stack Hub 的 SDN 拓扑与 ToR 配置在 OEM 集成系统出厂时已验证，Operator 不应自行修改 ------这一点是与公有云 Azure 最大的差异：本地云环境下，所有"硬件 + 网络"都是 OEM 集成包整体交付的，Operator 是"运营"而不是"自己组装"。

2.4 存储：S2D 三镜像 + ReFS + BitLocker

Azure Stack Hub 的存储由 Storage RP（SRP） 暴露，底层是 存储空间直通（Storage Spaces Direct, S2D）：

三镜像（Triple Mirror） ：Azure Stack Hub 强制使用三副本，不可改为双副本或 Parity ------这是 L1 微软硬要求；
ReFS：Resilient File System 提供数据保护与校验；
BitLocker：静态数据加密（结合 Azure Active Directory 提供密钥保护）。

关键边界 ：Azure Stack Hub 的存储模型与 Azure Stack HCI / Azure Local 不同 ------后两者允许在一台 Scale Unit 内根据业务特征选择 Mirror / Parity；Azure Stack Hub 强制三镜像 + ReFS + BitLocker ，不向 Operator 开放更改选项。

3. Azure Stack Hub 虚拟机类型：入门级 / 通用型 / 计算密集型

Azure Stack Hub 的虚拟机类型是 Azure 公有云 VM 系列的一个子集。这一点与 Azure Stack Hub 的"Azure-consistent 体验"定位直接相关。

3.1 三档 VM 类型速览

类别	典型 Series	典型用途	与 Azure 公有云对比
入门级	A / Av2	开发测试、低负载 Web、教学	VM 配置与 Azure 一致
通用型	D / Dv2 / DS / DSv2 / F / Fs / Fsv2	业务应用、中间件、数据库	VM 配置与 Azure 一致
计算密集型	F / Fsv2	计算批处理、CI/CD、游戏服务器	VM 配置与 Azure 一致

注意：可用 VM 系列随 Azure Stack Hub 版本演进，不同时期的版本支持的系列可能不同 ------这是 L0 版本事实 。本文不列出具体支持矩阵 ，实际部署前请以 当版本 Azure Stack Hub Operator 文档 中的 "VM sizes" 章节为准。

3.2 与 Azure 公有云的对比

Azure Stack Hub 与 Azure 公有云在 VM 类型上有 三个关键差异：

维度	Azure 公有云	Azure Stack Hub
VM 系列数量	数十个系列（涵盖 GPU / HPC / 内存优化等）	当前主流版本支持的系列是 Azure VM 系列的一个子集
配置（vCPU / RAM / Disk）	微软定义	同系列 VM 的 vCPU / RAM / 磁盘大小数量与 Azure 公有云一致
存储性能	由 Azure 后端存储决定	由 Operator 基础设施（OEM 推荐的磁盘型号 + 容量）决定
CPU 性能	由 Azure 分配的硬件决定	在低负载环境下，单 VM 的 CPU 性能可能优于 Azure 公有云（因为 Azure Stack Hub 物理 CPU 独占）

实操含义 ：当业务从 Azure 公有云迁移到 Azure Stack Hub 时，VM 大小（vCPU / RAM / 磁盘）可以保持一致 ，但 存储性能与 CPU 性能需要重新评估------这是从公有云迁回本地最容易踩坑的地方。

3.3 VM 伸缩集（VMSS）

VMSS（Virtual Machine Scale Set） 是 Azure Stack Hub 与 Azure 公有云保持一致的 横向扩展能力：

统一伸缩：在 Scale Set 内批量部署 / 横向扩展 VM。
内置 Gallery ：Azure Stack Hub 提供 VMSS Gallery 模板，简化 Scale Set 部署。
自动伸缩 ：当前版本 Azure Stack Hub 的自动伸缩 通常基于 ARM alert + runbook 实现，而非原生 insight-driven 模式。

版本演进提示 ：Azure Stack Hub 的 VMSS 行为在不同版本之间可能有所差异，自动伸缩的具体实现方式 以当版本 Operator 文档为准。本文不展开具体实现细节。

4. Azure Stack Hub 计算性能：从仿真模型到实测特征

"Azure Stack Hub 的 VM 性能与 Azure 公有云一致"------这是早期资料中常见的"仿真"描述。但 真正落地时必须理解仿真的边界。

4.1 仿真（Emulation）聚焦什么

Azure Stack Hub 的"仿真"主要聚焦于 VM 配置层面：

RAM / vCPU / 磁盘大小 / 数量 与 Azure 公有云一致------这是 配置层面的仿真；
VM 类型名称 （A / D / DS / F 等）使用 Azure 公有云相同的命名------这是 API 层面的仿真；
VM 部署 / 删除 / 启动 / 停止 等操作的语义保持一致------这是 行为层面的仿真。

4.2 仿真不覆盖的性能维度

以下维度的性能 不由 Azure Stack Hub 仿真 Azure 公有云 ，而由 本地基础设施 决定：

维度	Azure 公有云	Azure Stack Hub
CPU 性能	由 Azure 后端硬件决定	低负载下 VM 的 CPU 性能可能优于 Azure 公有云（独占物理核）
存储 IOPS / 带宽	由 Azure 后端存储决定	由 OEM 推荐的磁盘配置 + S2D 三镜像开销决定，通常与 Azure 公有云量级接近，但具体数值依硬件配置而定
网络出栈带宽	由 Azure NIC SKU 决定	与 Azure VM 相同 VM 大小下的出栈带宽上限一致
CPU 性能稳定性	由 Azure 调度决定	对给定 VM 大小，CPU 性能不是 100% 确定（取决于租户 VM 在物理主机上的实际放置）

4.3 性能评估建议

本节建议是 L3 最佳实践，非微软硬要求。

不要依据 Azure 公有云的性能基线直接搬到 Azure Stack Hub------重新跑一次业务负载测试。
关注存储性能 ：Azure Stack Hub 的存储性能由 磁盘介质（NVMe / SSD / HDD）+ 容量配置 + Scale Unit 节点数 共同决定，没有固定数值。
CPU 性能做边界测试：在高负载（如 90%+ CPU 利用率）下，Azure Stack Hub 的 CPU 性能可能与 Azure 公有云有明显差异。
出栈带宽：按 VM 大小对应的 Azure VM 上限参考，但实际能达到该上限取决于 ToR 交换机 / 物理网卡 / BGP 配置的整体能力。

5. 一致的部署体验：GitHub 模板 / PowerShell / Visual Studio

Azure Stack Hub 的核心承诺之一是 Azure-consistent 体验 。在"部署"这条主线上，模板、PowerShell、IDE 三个入口都保持与 Azure 公有云一致。

5.1 通过 GitHub Azure Stack Hub QuickStart 模板部署

GitHub 上的 Azure Stack Hub QuickStart 模板 是早期 Azure Stack Hub 社区最常用的部署入口：

仓库示例：Azure-Samples/Azure-Stack-Hub-Flask-App / Azure-Samples/Azure-Stack-Hub-MySQL-Demo 等。
关键操作 ：使用 标注为 Azure Stack Hub 适用 的模板------并非所有 Azure 公有云模板都能直接迁移。

重要提示 ：本节内容基于 2017-2018 年期间 Azure Stack Hub 社区生态整理。当前主流的 IaC 范式 已经演进到 Azure Verified Modules for Bicep / ARM Template + Terraform AzAPI / Pulumi 等多种工具组合；本文不预测社区工具链的演进路径，实际部署时请以当版本 Operator 文档与社区活跃仓库为准。

5.2 通过 PowerShell 部署

PowerShell 是 Azure Stack Hub 管理的核心工具：

当前主流推荐 ：Az PowerShell 模块 （Az.Accounts / Az.Compute / Az.Resources 等）。
历史模块 ：早期 AzureRM 模块已经在 2024 年 2 月 29 日退役 ------本文使用历史资料中出现过的 AzureRM 描述时，仅作为历史背景 ，不做"现在还在用"的暗示。
官方文档 ：Install PowerShell Az module for Azure Stack Hub - Azure Stack Hub | Microsoft Learn（具体路径以当版本为准）。

5.3 通过 Visual Studio 部署

当版本参考（Visual Studio 部署方向）：

早期资料中提到的 Visual Studio Community 2015 with Microsoft Azure SDK 2.9.6 是 2017-2018 年期间 的参考组合，当前版本的 Visual Studio 与 Azure SDK 都已经历多代演进。
当前主流做法 ：使用 Visual Studio 2022 + Azure development workload + Azure SDK （具体版本随 Visual Studio 发布节奏更新），通过 Connected Service 接入 Azure Stack Hub Operator Portal 的管理端点。
官方文档 ：Install Visual Studio and connect to Azure Stack Hub - Azure Stack Hub | Microsoft Learn（具体路径以当版本为准）。

实操建议 ：对于生产环境的部署，优先使用 Bicep / ARM Template + PowerShell / GitOps 自动化 ，Visual Studio 主要用于开发调试------这一点与 Azure 公有云的最佳实践一致。

6. 托管磁盘：把存储账户与伸缩限制藏起来

托管磁盘（Managed Disks） 是 Azure Stack Hub 在 存储管理 上的重要简化能力。

6.1 核心能力

能力	含义	价值
隐藏存储账户	租户不再需要手动创建 Storage Account / Blob Container 来挂载磁盘	降低使用门槛
隐藏伸缩限制	租户不再受 Azure 公有云 Storage Account 的 IOPS / 容量上限约束	Azure Stack Hub 通过本地 S2D 提供容量，缩放模型由 Operator 容量规划决定
更简单的管理	磁盘是 ARM 资源，与 VM 平级，可独立管理	与 Azure 公有云体验一致
访问控制粒度	磁盘是顶层 ARM 资源，可应用 RBAC / 资源锁 / 标签	治理更精细

6.2 关键边界

本节内容基于早年期间 Azure Stack Hub 托管磁盘初次引入时的描述整理 。当前版本 （2406 / 2503 等）托管磁盘的实现细节可能与下文描述有差异，实际部署前请以当版本 Operator 文档为准。

Azure Storage Account 限制在 Azure Stack Hub 上不适用 ------这是 早期实施层面的描述 ，当前版本的可访问性以 Operator 文档为准。
托管磁盘 vs 非托管磁盘 ：早期 Azure Stack Hub 版本同时支持托管与非托管磁盘；当前版本 已基本完成向托管磁盘的统一迁移，实际可用性以当版本文档为准。
官方参考文档 ：Azure Stack Hub managed disks differences and considerations - Azure Stack Hub | Microsoft Learn（路径以当版本为准）。

6.3 深入对比：托管磁盘 vs 传统存储账户

维度	传统存储账户 + vhd	托管磁盘
租户操作	创建 Storage Account → 创建 Container → 上传 vhd → 创建磁盘	直接创建磁盘（系统自动管理 Storage Account）
伸缩限制	每个 Storage Account 有上限（Azure 公有云）	Azure Stack Hub 通过本地 S2D 提供容量，缩放模型由 Operator 容量规划决定
访问控制	通过 Storage Account SAS / Access Key	直接在磁盘资源上应用 RBAC
审计标签	需要手动映射到 vhd	磁盘本身可打标签

7. 临时磁盘：被仿真为 VM 大小一部分的 D 盘

临时磁盘（Temporary Disk / Local Disk） 是 Azure Stack Hub VM 中一个 容易被误解 的组成。

7.1 临时磁盘是什么

定义：在 Azure Stack Hub 上，临时磁盘被仿真为 VM 大小的一部分 ，挂载为 D 盘 （Windows）或 /dev/disk/cloud/azure_resource-part1（Linux）。
存储介质 ：临时磁盘是 动态 vhd（而不是 OS 磁盘 / 数据磁盘的固定磁盘）。
生命周期 ：临时磁盘 与 VM 生命周期绑定 ------VM 卸载 / 故障转移时，临时磁盘数据会丢失。

7.2 关键技术细节

Windows 页面文件 ：微软推荐把 Windows VM 的页面文件（pagefile.sys）放在临时磁盘中 ------这是 L3 最佳实践 ，不是 L1 硬要求。租户管理员可以根据业务需求调整页面文件位置。
Linux 临时磁盘 ：Linux 上的临时磁盘默认挂载为 /mnt/resource / /mnt，应用程序可以临时使用。
VS 临时磁盘：DO NOT USE ------临时磁盘 不适合用于持久化数据。

7.3 临时磁盘 vs OS 磁盘 vs 数据磁盘

磁盘类型	用途	持久化	推荐使用场景
OS 磁盘	操作系统	持久化	操作系统 + 必要系统组件
数据磁盘	业务数据	持久化（受托管磁盘 Capacity 容量规划约束）	数据库文件、应用数据、用户文件
临时磁盘（D 盘）	临时数据	非持久化	页面文件、临时缓存、swap、中间计算结果

重要提示 ：很多企业用户第一次接触 Azure Stack Hub 时，会把临时磁盘当作"普通数据盘"使用，结果在 VM 故障转移时丢失数据 。请确保 所有持久化数据放在 OS 磁盘或数据磁盘上。

7.4 临时磁盘对性能的影响

本节为 L3 最佳实践，非微软硬要求。

临时磁盘的 IO 性能一般优于数据磁盘 （受物理节点本地 NVMe / SSD 限制），可用于临时 cache / scratch 空间。
不应假设临时磁盘性能绝对优于数据磁盘------具体性能取决于硬件配置与 VM 放置位置。
临时磁盘上的数据可靠性无法保证------请勿将关键业务数据写入临时磁盘。

8. 上篇小结

本篇我们沿着 架构 → 虚拟机类型 → 性能 → 部署体验 → 存储模型 的脉络，把 Azure Stack Hub 计算服务的 概述维度 拆解了一遍：

架构四层 ：计算能力由 ARM 控制面 + Hyper-V 群集 + 网络 SDN + 存储 S2D 四个子系统协同支撑，不是孤立的 Hyper-V 集群。
架构关键边界：Azure Stack Hub SDN 拓扑由 OEM 集成包验证交付、存储强制三镜像 + ReFS + BitLocker、租户 VM 与基础架构 VM 运行在同一 Hyper-V 集群但生命周期管理不同。
VM 类型 ：是 Azure VM 系列的一个子集；同系列 VM 的 vCPU / RAM / 磁盘大小数量与 Azure 公有云一致 ；存储性能与 CPU 性能由本地基础设施决定。
性能仿真边界 ：仿真聚焦于 配置 / API / 行为 三个层面；CPU / 存储 / 出栈带宽 的实测性能由本地硬件决定。
部署体验：通过 GitHub QuickStart 模板 / PowerShell（当前主流 Az 模块）/ Visual Studio（当前主流 VS 2022）三种入口进入，与 Azure 公有云保持一致体验。
托管磁盘 ：把存储账户与伸缩限制隐藏，向租户暴露简单的"ARM 磁盘资源"------这是 与 Azure 公有云体验一致的关键简化。
临时磁盘 ：被仿真为 VM 大小的一部分，挂载为 D 盘 （Windows）或 Linux 等价路径；用于页面文件、临时缓存、swap ；不适合持久化数据。
版本演进视角 ：本篇以早期 GA 介绍资料为基线，显式标注与当前版本的差异 ；实际部署时 以当版本 Operator 文档为准。

下篇我们将进入 管理与运维 维度：

Hub 基础架构 VM 生命周期：CRP 如何管理基础架构 VM、放置规则如何防止单点故障、Gen1 vs Gen2 区别。
计算资源管理与配额：内存耗尽 / CPU 配额 / 容量扩容的边界。
容量公式：可放置 VM 的内存计算公式、复原能力保留的物理含义。
添加节点：扩容 Scale Unit 的物理步骤与 OEM 验证流程。
市场镜像同步：第三方镜像 / 应用程序扩展 / 自定义镜像的取舍。

附录 A：本文涉及的关键概念速查

概念	定义	所在章节
ARM	Azure Resource Manager，控制面入口	§2.1
CRP	Compute Resource Provider，管理租户 VM 生命周期	§2.2, §3.3
NRP	Network Resource Provider，管控 VNet / PIP / NIC	§2.3
SRP	Storage Resource Provider，暴露 Storage Account / 磁盘	§2.4
S2D	Storage Spaces Direct，存储空间直通	§2.4
Hyper-V 群集	Azure Stack Hub 物理服务器的虚拟机承载层	§2.2
Scale Unit	一组协同提供 Azure Stack Hub 服务的物理服务器集合	§4
VMSS	Virtual Machine Scale Set，横向扩展能力	§3.3
托管磁盘	由 Azure Stack Hub 管理的持久化磁盘资源	§6
临时磁盘	与 VM 生命周期绑定的临时磁盘（D 盘）	§7
基础架构 VM	由系统内部管理、租户不可见的 VM（ACS / CRP / NRP 等）	§2.2

附录 B：参考文档

路径以当版本 Azure Stack Hub Operator 文档为准 ；本文列出的 URL 是 当版本 Active 期间 的入口地址，不预测未来路径变更。

Azure Stack Hub Operator 文档主入口：Azure Stack Hub Documentation - Tutorials, API Reference | Microsoft Learn
VM 大小（Azure Stack Hub）：https://learn.microsoft.com/en-us/azure-stack/operator/azure-stack-vm-sizes
托管磁盘注意事项：https://learn.microsoft.com/en-us/azure-stack/user/azure-stack-managed-disk-considerations
添加节点（扩容 Scale Unit）：Add scale unit nodes in Azure Stack Hub - Azure Stack Hub | Microsoft Learn
安装 Az PowerShell 模块：Install PowerShell Az module for Azure Stack Hub - Azure Stack Hub | Microsoft Learn
安装 Visual Studio：Install Visual Studio and connect to Azure Stack Hub - Azure Stack Hub | Microsoft Learn
市场镜像同步：Azure Stack Hub Marketplace overview - Azure Stack Hub | Microsoft Learn

作者：徐火军，Principal Engineer @ Dell Technologies，Azure Stack Hub 解决方案首席架构师。 下一篇 ：Azure Stack Hub 计算管理与运维：基础设施 VM 生命周期、配额、容量与扩容（下篇）