系统容器不是"轻量的虚拟机"：LXD/Incus 的存储池、网络与故障面怎么算

开篇：「轻量的虚拟机」这个说法错在哪一层

"把它理解成一台轻量级的虚拟机就行"——这句话在介绍系统容器时出现的频率高得离谱，而它的代价也高得离谱。前半句是对的，后半句是错的：轻量确实是事实，虚拟机不是。系统容器省掉的那一层，不是"虚拟化的厚度变薄了"，而是每个实例本来要各自携带的一整套东西——一份内核、一份固件与引导过程、一套随实例独立的设备模型——被整层拿掉了，换成所有实例共用宿主的那一套。省掉的是重复，换来的是共享，这两件事从来不在同一个方向。

这句话最贵的误导发生在隔离预期上。听到"虚拟机"，决策者脑中默认会挂上三条隐性承诺：它有独立的故障域，内核层面的问题只会砸它自己；它可以按自己的节奏重启与升级，不必和别人排队；它跑什么内核版本是自己的事。系统容器这三条一条都不成立。实例之间的确拥有独立的进程视图、网络视图与挂载视图，看上去像一台机器，但当宿主内核出问题时，它们会一起出问题，一次也不落下。

实际工程里，这个错配常常以很朴素的方式爆发。某个实例因为业务要求想开一个内核参数的值，运维在宿主上调完之后，同一台宿主上其余几十个实例的运行行为一起变了，其中某个服务的连接池行为不再正常；或者宿主需要升级内核修补一个问题，排期时发现没有任何一台宿主可以单独停机，因为每台上面都压着几十个实例，于是维护窗口被无限期推迟。这些都是"以为是虚拟机"带来的直接后果，跟工具本身的成熟度无关。

本文要回答的核心问题是：系统容器和虚拟机、应用容器，到底差在哪一层。我的判断是——差别不在性能，也不在密度，而在"被去掉的那一层由谁承担"。虚拟机把硬件虚拟化层放在隔离边界上，因此边界清晰但每个实例都要自带内核；系统容器把这条边界移到了内核内部的命名空间与控制组上，因此省掉了内核的重复开销，却让所有实例共享同一个宿主内核、同一套内核参数与同一组驱动。选型的关键从来不是谁跑得快，而是你能不能接受所有实例一起经历一次宿主内核升级、一次内核故障。

三种形态各自去掉了什么：虚拟机、系统容器、应用容器

把三种形态放在同一张图上比较，最有价值的切入点不是"谁更轻"，而是"各自砍掉了什么"。虚拟机在硬件虚拟化层做隔离，客户机拥有自己的内核、自己的固件与引导过程，从加电自检到内核解压到用户空间初始化，整条链路都是实例自备的。它看上去最重，但正因为重，它与宿主的耦合点最少：宿主内核版本与客户机内核版本互不牵涉，两边各自升级，互不阻塞。

系统容器去掉的正是这一整套。它没有自己的内核，直接运行在宿主内核之上，靠命名空间隔离进程树、网络栈、挂载点与用户身份，靠控制组限制资源用量。但它在"里面应当有什么"这件事上，取向和虚拟机是一致的：容器内跑的是完整的初始化系统（常见如 systemd），有自己的服务管理、日志体系、用户与包管理，可以像一台机器那样被 ssh 登录、被配置管理、被批量发放。这也是为什么它被叫做"系统"容器——它的建模对象是机器，而不是进程。

应用容器是另外一种取向。它以单个应用进程为中心，镜像按层组织，层与层之间可复用，通常不含初始化系统，主进程退出就意味着实例生命周期结束。它的强项在于分发与重建：镜像可以在任意节点上拉下来重建出一个行为一致的实例，实例本身不需要被"维护"。代价是对习惯了一整套系统管理工具的场景并不友好——你想在里面起第二个常驻服务，就得重新想一遍它的进程模型。

三种形态对运维提出的要求完全不同。虚拟机需要的是虚拟机管理层与镜像模板；系统容器需要的是宿主内核管理、存储池与网络规划；应用容器需要的是镜像仓库与编排层。用管理虚拟机的思路管系统容器，最容易踩的坑是把每个实例当成独立故障域去承诺可用性；用管理应用容器的思路管系统容器，最容易踩的坑是把它当成可随意丢弃的实例去重建，结果发现里面的数据与已发放的配置并没有那么容易被替换。

LXD 与 Incus 同源于 Linux Containers 社区维护的系统容器管理项目，两者在概念与操作方式上高度相近：都以"实例"为基本对象，都有存储池、网络、配置模板与远程管理的概念，都能管理虚拟机类型的实例。Incus 是社区治理调整后形成的分支。此处提醒一句：项目治理与命名以官方公告为准，本文不引用任何具体版本号与时间线，选型时请以官方发布信息为准。

共享内核意味着什么：故障面、内核参数与驱动一荣俱荣

共享内核不是一句抽象的话，它在运维日历上有三个具体落点。第一个落点是故障域：宿主内核一旦出现需要停机的严重问题，跑在这台宿主上的全部实例同步受影响，没有"只崩一个"的选项。这不是概率问题，而是结构问题——多少个实例在同一台宿主上，就意味着一次内核故障的影响面有多大。因此决定实例密度的变量里，"单个宿主的实例上限"应该由故障可接受范围倒推，而不是由资源余量倒推。

第二个落点是内核参数。内核参数是宿主级的，不是实例级的。某个实例因为业务需求想调某个网络或内存相关的参数，改完之后同宿主所有实例都在这个参数下运行。这意味着参数改动必须走与"修改一台机器的配置"完全不同的审批路径：它是一次影响面覆盖全宿主的变更，需要有明确的回滚方案，也要在变更记录里写清楚波及清单。很多团队在制度上对此毫无准备，第一次踩坑往往就是某次"临时调一下"。

第三个落点是驱动与内核模块。实例看到什么驱动能力，完全取决于宿主加载了什么；反过来，宿主加载的模块对所有实例同时生效。文件系统能力、网络卸载能力、加密与压缩相关的内核设施都属于这一类。共享内核在这里其实是效率的来源——只需要在一处维护驱动版本——但它同时也意味着驱动与内核版本之间多了一条双向约束。

这条双向约束的现实形态是这样的：宿主想升级内核，需要考虑现有驱动在新内核上是否需要重新编译或重新安装；某个驱动要求特定内核版本，反过来又把宿主内核钉在某个区间上。两边的节奏不一致时，冲突会以"升级被推迟"的形式长期存在。评估驱动供应商支持的内核版本范围，在系统容器场景里比在虚拟机场景里重要得多，因为虚拟机里这只是单个客户机的事，而这里它是整台宿主的事。

把这三件事叠在一起看，就会得到一个不太舒服但必须承认的结论：系统容器的运维重心，从"实例面"整体移到了"宿主面"。实例的创建与销毁可以很快，宿主的内核版本、参数、驱动、停机窗口却需要长期规划。团队如果没有人可以稳定承担宿主层的治理，那么密度收益大概率会被运维摩擦吃掉。这也是我建议把"宿主负责人"作为上生产前置条件的原因——不是流程形式，而是这个角色真的有活要干。

特权与非特权：用户命名空间这道分水岭

特权与非特权是系统容器配置里最重要的一刀，其重要性超过绝大多数可调项。非特权容器通过用户命名空间做 UID 与 GID 映射：容器内看到的 root（UID 0），在宿主视角是一个没有特权的普通用户 ID；容器内看到的某个业务用户，对应宿主上另一个被分配出来的区间 ID。这样安排的目的很直接——把实例内的身份与宿主上的身份解耦，即使实例内的权限边界被突破，落到宿主上的身份也仍然受限，影响范围因此被压缩。

需要强调的是，这一刀改变的是"越权之后的映射范围"，而不是"共享内核"这个前提。非特权容器依旧与宿主共用同一个内核，内核层面暴露的接口对所有实例同样存在，所以非特权不等于可以放进互不信任的多租户场合。讨论容器隔离强度时，我更倾向于使用两个可操作的指标：一是实例内的身份映射到宿主上是哪个 UID 区间，二是实例默认持有哪些权能与哪些设备可见。这两个指标比任何形容词都更能说明实际情况。

非特权的代价必须诚实说清楚。一部分操作在宿主上天然需要真实特权，非特权容器要么做不了，要么需要额外的配置与放行。典型受限项包括：加载与卸载内核模块、挂载某些文件系统类型、创建设备节点、部分需要原始网络能力的操作，以及某些存储池与网络后端的组合。这些限制不是缺陷，而是设计意图；真正危险的处理方式是"某个功能跑不起来，先改成特权容器再说"——一旦这么做了，前面那一刀的收益就被静默地退还了。

我的建议是建立一条默认规则和一个例外清单。默认规则：所有实例默认非特权。例外清单：每一台特权实例都要写明理由、写明需要哪些具体权能或设备、写明它为什么不能被拆成非特权加宿主侧代理的方式实现，并且定期复审。用"具体权能放行"替代"整体开特权"通常能让清单大幅缩短，因为多数需求其实只需要其中一两项能力，而不是整份特权。

还有一条容易被忽略的部署隔离原则：把必须以特权运行的实例集中到独立的宿主，不要和承载普通业务的实例混放。这条建议的出发点不是性能，而是让"需要放宽边界"的那一小撮实例有明确的物理边界。一旦混放，宿主的隔离等级就会被拉到最宽松的那台实例上，而这件事在文档里通常不会被记录，只能在事后复盘时被发现。

存储池是地基：后端类型直接决定快照、配额与迁移能力

系统容器的存储池是所有实例卷的载体，后端类型的选择属于典型的开局决策——选定之后要改，往往意味着数据要整体搬一次。常见的后端类型可以粗分为几类：基于普通目录的后端、基于块设备或逻辑卷管理的后端、基于写时复制文件系统的后端，以及基于网络存储的后端。它们的差别不在于"好不好"，而在于各自把哪几项能力做成了可用的、又把哪几项留成了不可用。

目录后端最容易上手，任何文件系统都能承载，排障时文件就在那里看得见摸得着。代价也很明确：快照往往要靠复制实现，空间与时间都随卷的大小线性增长；配额的精度与支持方式受底层文件系统约束；缺少高效的增量差异能力，在线迁移也就谈不上有多便利。这类后端的合理位置在开发测试环境、以及对迁移与快照要求不高的单机场景。

块设备与逻辑卷后端的思路是把每个卷挂到一个逻辑卷或块设备上，配额因此变得干净——卷多大就是多大，不会互相侵占；数据布局清晰，易于理解。它要求宿主上预留相应的卷组空间，也要在扩容时提前算好：容量不足时不是"删几个文件"能解决的，而是要动卷组。写时复制文件系统后端则把重点放在另一处：快照几乎是瞬间完成的，差异可以看出来、补出来，在线迁移因此可以做到只传增量，这对需要把实例从一台宿主挪到另一台宿主的场合非常关键。

写时复制带来的收益不是免费的。这类文件系统对内存与底层磁盘有要求，对写放大敏感，空间回收需要监控——快照存在期间，被快照引用的数据块不会被释放，所以磁盘剩余空间会随着快照链变长而变得难以预测。建议把"快照链长度"与"池可用空间"作为同一组监控指标来看，并设置明确的告警阈值，否则最容易出现的故障是：数据其实写进去了，但池在某天突然打满。

网络存储后端把数据放在共享的存储层上，实例因此在宿主之间挪动的难度明显下降，某些高可用方案也依赖这个前提。它同时引入了一层新的依赖：网络路径、存储集群的状态、以及访问延迟，都会变成实例的本地故障源。这不一定是坏事，但必须在故障面上单独记一笔——使用共享存储意味着把宿主层的故障面和存储网络的故障面叠加起来。

快照不是备份：和存储池同生共死的那部分数据

快照的心智模型需要严格校正一次。快照是"回滚点"，不是"副本"：它记录的是某个时间点的数据状态与后续差异，而这个记录本身停留在同一个存储池里。一旦存储池损坏——底层磁盘故障、文件系统损坏、误操作删除了池、或者宿主本身的存储不可用——快照会与原数据一起失效。把快照当成备份的团队，通常是在真正需要恢复的那一刻才发现这个问题，而那一刻已经没有重来的机会了。

由此可以得到一条非常朴素的判断：一份数据只有存在第二个物理位置的副本时，才算备份。落到操作层，就是把卷或快照定期导出为独立的归档，放到与存储池不同的介质、不同的宿主、最好不同的机房，并且对这批归档做独立的生命周期管理——保留多久、怎么验证可恢复、过期如何清理。这套流程和存储池用什么后端是正交的：后端决定快照好不好用，这套流程决定数据掉不了。

第二个容易被低估的点是验证。备份的价值在恢复时才兑现，而恢复流程在没有演练过的环境里，第一次执行往往失败：目标的目标路径不对、权限不一致、归档格式与导入方式不匹配、或者导出时的网络路径已经变更。建议把"定期做一次真实恢复演练"写成有明确责任人的周期性任务，演练结果要能回答两个问题：恢复到业务可用需要多久，以及恢复出来的数据是否完整。

第三个点是留存策略要和业务粒度对齐。快照可以做到很密（分钟级也可以），但它只能在同一池内快速回滚，用来应对"刚刚改错了"这类短窗口问题；归档副本适合按天或按更小的时间单位做，用来应对"数据损坏了一段时间才发现"这类长窗口问题。两者保留时长不同、覆盖范围不同，把它们混成一套策略，通常的结果是哪一头都没覆盖好。

还有一个运维细节值得写进规范：谁有权执行删除。删除卷、删除快照、删除存储池，这三类操作的破坏半径完全不同，应当有不同的权限与二次确认要求。尤其是"删除池"这一级，它同时清掉上面所有的卷与快照，操作者在界面上看到的往往只是一行确认提示，而实际影响是整个池里的全部数据。

网络怎么给：桥接、直通与地址规划的三个常见坑

网络形态的选择直接决定实例的二层可见性、宿主的运维可达性，以及出网流量的地址呈现。常见做法大致有四类：在宿主上建桥，把实例挂到桥上；用 macvlan 或类似机制让实例直接出现在物理二层；把整张物理网卡直通过给某个实例；以及用虚拟网络方案，在宿主内部做交换与三层转发，实例通过 NAT 或路由出网。四类各有适用范围，混用时也各自清楚一些约束。

第一个坑在桥接：很多排障故事都发生在"宿主既是桥又是主机"这个身份上。宿主自身的 IP、实例的 IP、默认网关都在同一张二层里，一旦宿主上还有网络管理工具在同时管理这张网，就很容易出现配置互相覆盖、变更前后的连接短暂中断、或者变更后管理通道直接失联。建议的做法是把宿主管理口与实例桥明确分开，并且在每次网络变更前确认"改完之后还能不能登上去"这条底线。

第二个坑在 macvlan 这一类方案：实例获得独立的二层身份直接出现在物理网络上，看起来最"像物理机"，但宿主到这些实例的通信路径在特定模式下会受到限制。也就是说你从宿主上去 ping、去连自己这台机器上的实例，反而可能不通。这在生产上最常见的后果是监控与运维通道失效——监控服务器侧看起来正常，宿主侧就是采不到。解决办法不复杂：宿主与实例之间另外留一条明确的管理通路，别指望走业务那张网。

第三个坑是地址规划，它不出故障的时候毫无存在感，出故障的时候很难收拾。IPv4 地址池要算实例总数、宿主数量与冗余，不能建到一半发现不够，因为补地址意味着重新规划网关与掩码；IPv6 地址通常不再稀缺，但需要提前决定每个宿主或每个实例拿到的是哪一级前缀，并在交换机端口与防火墙策略上同步放开；采用 NAT 出网时必须清楚源地址会被转换，这会直接影响日志、审计与基于来源的访问控制，必要时把原始地址信息通过代理协议或日志字段显式传递出去。

还有一个经常被忽略的问题是双栈不一致。IPv4 通、IPv6 不通（或反过来）在网络改造后相当常见，而很多服务在双栈环境下会优先走其中一种，导致表现出来的现象是"时快时慢、偶尔超时"。把双栈的一致性检测纳入常规巡检，比事后抓包要省事得多。另外记得为实例的域名解析留出明确配置路径——系统容器内的网络配置往往需要显式指定，而不是自动继承宿主。

设备直通与 GPU：共享内核在这里既是优势也是限制

设备直通是最能体现"共享内核"双面性的地方。优势那一面很好理解：驱动只在宿主上安装一次，实例只要被授予访问该设备的权限就可以使用，不需要为每个实例准备一套独立的驱动栈，也不需要像虚拟机那样考虑客户机内部的驱动兼容性。对于 GPU、加密卡、特定加速设备这类驱动体积大、安装过程敏感的设备，这一点在实际运维中节省的工作量相当可观。

限制那一面同样清晰：驱动与宿主内核版本绑定。部分驱动需要在特定内核版本下编译或做接口匹配，宿主一升级内核，驱动就可能失效需要重新安装或重新编译；反过来，某个驱动支持的内核版本范围，也会把宿主内核钉住。前面说过虚拟机里这是单个客户机的问题，这里它是整台宿主的问题——一次驱动故障影响的是同宿主的全部实例。

再往下看，直通还带来两个结构性后果。其一是分配单位：算力类设备直通后通常是独占式的，一张卡给了某个实例，别的实例就用不了，除非采用其他共享机制。这意味着容量要按"卡"而不是按"可用比例"来算，调度时要明确记账：谁在用哪张卡、还有几张空闲、哪些宿主上已经没有余量。其二是迁移约束：设备在本地，实例就不太可能被在线迁到另一台宿主上。带直通设备的实例天生比普通实例"粘"在宿主上，这一点必须在调度策略里就区分开来。

由此得出一条直接的部署建议：把承载直通设备的宿主与普通宿主分成不同的资源池。分池的好处不止于调度清晰——它还把这批宿主的变更窗口、内核升级策略、驱动维护流程自然地分开了。普通宿主可以按常规节奏滚动升级，带设备的宿主则要等设备驱动就绪再动，两者节奏不同步是常态，硬把它们绑在一套流程里只会互相拖累。

USB 与块设备直通属于另一类细节，需要单独提醒：热插拔后设备节点可能变化，实例内的绑定关系不一定随之更新；块设备直通则意味着实例直接掌握了底层的写入路径，宿主侧的文件系统层保护在这里是不存在的。权限配置要做到最小必要，并且记录在配置模板里，避免每次重建实例时靠记忆补参数。

什么场景该用它，什么场景该老实用虚拟机

先说适合的一侧。系统容器最贴合的场景，是"需要一堆能被当成机器来管理的 Linux 实例"。典型例子包括：开发与测试环境的批量发放，每个环境要跑好几个服务、要能被 ssh 进去折腾、要能长期存在并按快照回滚；把一台物理机上原本混跑的多个传统服务拆成若干台相对独立的实例，每个里面仍然用初始化系统托管进程；边缘或分支机构的小节点，硬件资源有限，但要跑若干独立服务；以及作为构建、测试、批处理任务的隔离执行环境，任务之间需要干净的依赖树又不希望背负完整的虚拟化开销。

再说应当果断走虚拟机的一侧。互不信任的多租户是第一位的：不同团队、不同客户、甚至不同安全等级的服务共享同一内核，意味着共享同一个故障面与同一份内核版本约束，这在多数合规语境下都说不过去。第二位是跨内核版本混跑：某些服务明确要求特定发行版与特定内核版本，或者就是要用非 Linux 系统，这只有虚拟机能承办。第三位是固件级的需求独立引导过程、独立设备模型、或者对虚拟化层隔离有明确要求的安全基线。

还有一种判断方式是从"坏了之后怎么办"倒推。需要修复、需要保留当时状态、需要长期维护配置漂移的，偏系统容器；发现异常就地销毁、拉同样镜像重起一个的，偏应用容器；出问题要整机搬走、或者要独立的故障域与引导过程的，偏虚拟机。这个判断标准的实用之处在于，它绕开了性能与密度的争论，直接对着团队的处置习惯提问。

现实中多数环境不是三选一，而是两层叠加：底层宿主跑虚拟机获得强隔离与独立的维护性，虚拟机内部跑应用容器获得分发与弹性；系统容器处在两者之间那一格，用它来承接那些"想要机器的管理手感、又能接受共享内核"的工作负载。这种混合结构没什么问题，前提是每一层承担什么边界要在文档里写清楚，不要指望某一层顺手解决另一层的问题。

有一条常被忽略的成本要提前算：系统容器的密度优势要靠宿主层的治理能力来兑现。宿主越多，内核版本一致性、补丁推送、驱动更新、停机窗口排期的工作量就越大。如果团队规模不足以稳定承担这些，密度收益会被运维负担抵消，最终表现为"机器是省下来了，人是加进去了"。这不是反对用它，而是提醒把人力成本算进总体的方案账里。

上生产前的验收顺序

验收顺序的重要性不亚于任何一项具体配置。第一步必须是定故障面，而不是定性能。请把这句话写下来并让相关方签字：一台宿主上最多放多少个实例，一次宿主内核故障最多允许影响多少个业务。这个数字一旦确定，密度、资源预留、实例分布就都有了约束条件，后面的所有选择都能在这个框架里评估。

第二步是存储池后端定型，并在真实数据量级上验证三项能力：快照创建与回滚是否达到预期、配额是否被精确执行、以及在线迁移能否完成且增量是否合理。验证要用接近生产的卷大小，不要用几百兆的卷试过就说结论。

第三步是网络形态与地址规划落地。先画一张表：每种业务用哪种网络形态、地址从哪个池分配、双栈是否一致、运维与监控通道走哪条路径、NAT 场景下源地址信息如何传递。这张表要在上线前定稿，不能边上线边补。

第四步是特权策略。默认非特权，例外清单逐项登记，并且检查每一项是否可以用更窄的权能放行替代。同时确认必须特权的那批实例已经落到独立宿主，不与常规实例混放。

第五步是备份链路：独立于存储池的副本在什么位置、多久一次、保留多久、谁负责验证。第六步是内核升级演练——请真的跑一遍：怎么把宿主上的实例腾出去、需要多久、有没有拒绝迁走的实例、失败了怎么回滚。第七步是监控覆盖：内核日志、存储池剩余空间、快照链长度、网络连接状态这些宿主层指标必须单独成组并要求告警，因为它们在实例视角里是看不见的。

省掉的是内核，换来的是共同的故障面

回到开篇那句话。系统容器省掉的，是每个实例各自持有的一份内核与固件，以及随之而来的重复开销；换来的是所有实例共享同一个宿主内核、同一套内核参数与同一组驱动。这个交换的两端都是真的，也都必须被计入账内——只算省下来的那一半，就会得出"它就是更便宜的虚拟机"这个错误结论，并以最贵的方式在第一次宿主内核事故时结清。

所以选型的关键从来不是性能谁高、密度谁好，而是两个能不能接受：能不能接受所有实例一起经历一次宿主内核升级，能不能接受一次内核故障让整批实例同时停下。这两个问题的答案如果是能，系统容器提供的"像机器一样管理"的手感与密度收益才真正成立；如果答案是否，那就老实用虚拟机把隔离边界放回到硬件虚拟化层，多出来的开销换来的是独立性与维护自由度。

还有一条必须始终挂在心上的边界：快照不等于备份。快照与所在的存储池共享生命周期，池坏则快照同归于尽，能用来快速回滚，不能用来对抗介质损坏与误删除。真正算数的备份是第二个物理位置上的那份副本，以及一份被演练验证过的恢复流程。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准，容器与虚拟化的隔离形态请以自有环境验证为准。

本篇关于系统容器的边界与信息来源

本文的定位是架构选型与运维边界的判断，不是安装部署教程，因此不提供具体的安装步骤、命令参数与配置文件写法。涉及命令行与配置项的部分，请以官方文档与发行版仓库的说明为准；不同发行版打包的版本差异、不同存储后端的支持范围，都可能导致具体操作存在差别。

关于 LXD 与 Incus：两者同源于 Linux Containers 社区维护的系统容器管理项目，概念与操作方式高度相近，Incus 是社区治理调整后形成的分支。项目治理与命名以官方公告为准，本文不对版本号、发布时间线与功能差异做具体陈述，也不建议依据二手资料判断两者的取舍。

关于安全：本文只从隔离边界、映射范围与故障面角度讨论强度，不涉及任何具体的安全漏洞细节、缺陷成因或攻击手法，也不提供相关指引。涉及合规要求的场合，请以自己的安全基线与官方安全公告为准。

关于数字与价格：本文刻意不给出任何启动耗时、密度倍数、IO 吞吐等实测数字，凡需要量化的地方一律以自有环境验证为准。涉及资源购置与租用成本时不做报价，相关商务条款需实时询价，实际价格主要受 CPU、内存、存储、带宽、IP 与线路等因素影响，以官网实时信息或咨询确认为准。