星核火花赛车科技

标签： 车型平台

  • Honda 平台表：38 个条目里的 DBC、flags 与线束提示

    结论：Honda 的平台表把三类东西放在不同层：软件平台定义（固定快照里 38 个 Honda/Acura 条目）、DBC 与 flags、以及 HondaCarDocs 的线束提示。三者不能互相替代——同 DBC 不等于同线束，CAN FD DBC 不等于 CAN FD 平台，文档线束提示也不等于接线验证。任何车型插件都必须冻结精确平台 ID、DBC 哈希、静态与动态 flags、物理总线图与线束版本，不能只凭「Bosch/Nidec」或 DBC 文件名授予控制权。

    38 个平台条目：计数的是代码平台

    在固定快照 c8fb906 的 CAR 枚举里，Honda/Acura 有 38 个平台条目：26 个 Bosch 配置，其中 7 个为 HondaBoschCANFDPlatformConfig，另有 12 个 Nidec 配置。源文档强调，这里计数的是代码平台，不是市场车型、年款或可装车数量。

    HondaBoschCANFDPlatformConfig 继承 Bosch，构造时加 BOSCH_CANFD，并默认 PT DBC 为 honda_common_canfd_generated；HondaNidecPlatformConfig 加 NIDEC，各平台通过 radar_dbc_dict() 同时声明 PT DBC 与 acura_ilx_2016_nidec 雷达 DBC。

    软件类别 代表平台 DBC / flags 含义
    Bosch 有雷达 HONDA_ACCORD、HONDA_CRV_5G PT DBC 依车型而异；BOSCH_ALT_BRAKE 可为静态标志，也可由指纹条件补上。
    Bosch 无雷达 HONDA_CIVIC_2022、HONDA_HRV_3G、ACURA_ADX BOSCH_RADARLESS 使车端总线、按钮目标和纵向权限走不同分支；不能只按 DBC 名判断。
    Bosch CAN FD HONDA_ACCORD_11G、HONDA_CRV_6G、ACURA_MDX_4G_MMR BOSCH_CANFD 标志和默认 PT DBC 一起定义平台；本快照参数层不开放 CAN FD 实验纵向。
    Bosch 非 CAN FD 但复用 CAN FD DBC ACURA_MDX_4G PT DBC 仍是 honda_common_canfd_generated，源码注释明确「not CANFD car but shares same dbc」；安全模式和总线拓扑不能由 DBC 文件名反推。
    Nidec HONDA_CIVIC、HONDA_CRV、HONDA_ODYSSEY PT/雷达双 DBC；NIDEC_ALT_SCM_MESSAGES、NIDEC_ALT_PCM_ACCEL 和全车门字段标志决定输入/输出分支。

    CarSpecs 与参数复用不等于实车测定

    CarSpecs 给质量、轴距、转向比、质心前轴比、最低转向/使能速度和轮胎刚度因子；通用 get_params() 将其写入 CarParams，并加默认载荷后计算惯量/轮胎刚度。平台间存在显式参数复用：旧 HONDA_HRV 复用 HONDA_HRV_3G.specs，旧 HONDA_PILOT 复用四代 Pilot 的 specs。源文档提醒，这是代码共享，不是目标车辆物理参数已经测定的证据。

    CarInterface._get_params() 把静态平台资料与指纹、固件、用户选择合成为实际 CarParams 和 safetyParam；CarState.get_can_parsers() 按 PT/相机/车身路由建立解析器，RadarInterface 在 Nidec 平台另用 Bus.radar DBC 建立雷达解析器，CanBus/CarControllerParams 再把车型能力映射为物理总线与转向扭矩上限。源文档据此把「平台表」定位为软件声明，而不是可直接施工的线束图。

    静态 flags、指纹动态标志与总线映射

    平台表中的 BOSCH、NIDEC、BOSCH_RADARLESS、BOSCH_CANFD、BOSCH_ALT_RADAR 是构造时的静态能力。CarInterface._get_params() 还从指纹动态设置 BOSCH_EXT_HUD、HYBRID、条件性的 BOSCH_ALT_BRAKE 以及特定五代 CR-V 的 HAS_BSM；固件 EPS 版本含逗号则置 dashcamOnly。BOSCH_TJA_CONTROL 在控制器有分支，但本快照平台定义中未见设置，不能把 dormant 代码当作已开通能力。

    CanBus 把 Bosch 有雷达平台的 PT 映射到 offset+1、radar 到 offset，纵向模式影响 LKAS 发送总线；radarless/CAN FD/Nidec 使用另一组映射。CarState 的相机解析器使用同一 PT DBC，却绑定 CanBus.camera 物理输入；BSM parser 使用 Bus.body DBC 但读取 CanBus.radar，需要 panda 转发 B-CAN。源文档据此总结：DBC 语法共用、逻辑 Bus 名称和真实总线接线是三个不同层次。DBC 语法共用不代表物理总线相同。

    这些 flags 的取值分支会一路传到构帧与限幅：例如 BOSCH_RADARLESS 影响车端总线与按钮目标，纵向模式影响 LKAS 发送总线。因此只按 DBC 名或品牌判断输入/输出分支，会同时误判总线映射与限幅参数。

    线束提示只是文档族

    HondaCarDocs.init_make() 按 flags 选择文档线束族：Bosch CAN FD 为 bosch_c，radarless 为 bosch_b，其他 Bosch 为 bosch_a，Nidec 为 nidec。CarDocs 的年款、最低转向速度、套件和 AEB/FCW 脚注用于支持表呈现，不构成引脚、供电、继电器或 EMC 的工程验收。部分平台 car_docs=[] 只是不在支持表展示，不代表平台代码不存在。

    把这些层叠起来看：平台表决定「软件认为这是什么车」，flags 决定「走哪条分支」，DBC 决定「怎么解析字段」，线束文档决定「支持表怎么展示」，而物理接线与 ECU 固件证据是独立的一层。四者只有在插件描述符里逐项冻结，才谈得上可复现。

    插件描述符必须冻结什么

    必须冻结的字段 为什么不能省
    精确平台 ID、DBC 哈希 同 DBC 不等于同线束；ACURA_MDX_4G 复用 CAN FD DBC 却是非 CAN FD 平台。
    静态 flags（BOSCH / NIDEC / BOSCH_RADARLESS / BOSCH_CANFD） BOSCH_RADARLESS 会使总线、按钮目标和纵向权限走不同分支。
    动态 flags（EXT_HUD / HYBRID / ALT_BRAKE / HAS_BSM / dashcamOnly） 由指纹与固件条件设置，不能只按 DBC 名或品牌判断。
    物理总线图、线束版本 逻辑 Bus 名称与真实接线是不同层次，DBC 名不能反推拓扑。
    ECU 固件证据、panda safety 模式 决定控制权授予与失联回退，不能只靠「Bosch/Nidec」授予控制权。

    源文档给出的顺序是：先建立目标车型的只读 CAN/电源/接线记录，再验证 PT、camera、radar、body 路由、原车 ADAS 保留和失联回退；没有原厂资料和台架证据，不把文档线束类型当作可照抄的接线表。此处仅完成静态结构分析，未验证 38 个平台的实际车辆参数或装配兼容性。

    常见问题

    38 个 Honda 平台条目等于 38 款可装车型吗？

    不等于。源文档明确，这 38 个是代码里的平台条目（26 个 Bosch 配置含 7 个 CAN FD 配置，加 12 个 Nidec 配置），计数的是代码平台，不是市场车型、年款或可装车数量。

    用了同一个 CAN FD DBC，是否说明这平台就是 CAN FD 车？

    不是。ACURA_MDX_4G 的 PT DBC 仍是 honda_common_canfd_generated，但源码注释明确它「not CANFD car but shares same dbc」，说明安全模式和总线拓扑不能由 DBC 文件名反推。

    文档线束提示（bosch_a/b/c、nidec）可以直接照抄接线吗？

    不可以。这些是 HondaCarDocs.init_make() 按 flags 选择的文档线束族，用于支持表呈现，源文档明确它们不构成引脚、供电、继电器或 EMC 的工程验收。接线仍需原厂资料与台架证据。

    BOSCH_TJA_CONTROL 出现分支，是否代表该能力已开通？

    不代表。源文档指出它在控制器里有分支，但本快照的平台定义中未见设置，属于 dormant 代码，不能当作已开通能力。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/HONDA_PLATFORM_DBC_HARNESS_MATRIX_DEEP_DIVE.md（取用了平台类别计数、静态与动态 flags 分层、总线映射与线束文档族选择逻辑）。

    说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • body、BYD、MG、PSA 与 mock：五种平台的执行语义与资格标记

    结论：在固定快照 c8fb906 中，body、BYD、MG、PSA 与 mock 这五个平台各有完全不同的执行语义：body 是双轮开发平台而非乘用车，只做左右轮速度与差速；BYD 与 PSA 走转角链，MG 走扭矩链；mock 返回空状态与空发送，只在无法识别车型时回退。BYD、MG、PSA 在快照中均被标记 dashcamOnly，其 panda 安全模式仅在 ALLOW_DEBUG 注册，因此不能把代码路径解读为发布固件可用功能。本文为静态代码分析，未运行测试、未做实车验证。

    平台资格：notCar、dashcamOnly 与调试注册

    同一套接口在不同平台上可能只是「能加载」而不是「允许执行」。body 通过 CarInterface._get_params() 设置 notCar=True，它并不是乘用车；BYD、MG、PSA 与 mock 都设置了 dashcamOnly=True，且它们的安全模式只出现在调试注册表里。插件清单必须把这几类资格分开标注。

    平台 控制语义 资格标记
    body 双轮差速、速度控制 notCar=True，非乘用车
    BYD 角度转向、原车纵向 dashcamOnly=True，调试注册
    MG 扭矩转向、原车巡航 dashcamOnly=True，调试注册
    PSA 角度转向、EPS 重使能 dashcamOnly=True，调试注册
    mock 空状态、空发送 dashcamOnly=True，未知车型回退

    body：开发用双轮平台

    CarState.update() 从电机数据读取左右电机速度并估算速度，电机错误会形成永久转向故障，同时读取充电与电量，且巡航状态被设为可用且已启用。CarController.update() 与构帧函数把 actuators.accel 与 torque 转成期望前进速度与左右差速，使用两个 PID，经过死区、变化率及幅度限制，最终编码双轮扭矩；代码明确注明加速度字段并非真实加速度语义。

    body_rx_hook() 在 RX 有效后允许控制，body_tx_hook() 只开放指定 TX 地址与长度并关闭转发。需要注意两处例外：未允许控制时仍可发送 0x1，且 0x250 的特定魔数刷写帧也被放行。固件没有乘用车式的双轮扭矩逐字段限制，因此它的安全策略不能移植到车辆。

    层 关键函数 实现事实
    参数 _get_params() notCar=True、body 安全模式、纵向开启、角度控制类型
    输入 CarState.update() 左右电机速度估算速度；电机错误形成永久转向故障
    输出 CarController.update() / create_control() accel 与 torque 转差速，经死区与限幅编码双轮扭矩
    固件 body_rx_hook() / body_tx_hook() 仅白名单与长度；未允许时仍可发 0x1，0x250 刷写帧为例外

    BYD 与 MG：转角链与扭矩链

    BYD 走角度转向：CarController.update() 用车辆模型限制目标转角，每两帧发转角与 HUD，取消时每十帧发按钮候选帧；byd_tx_hook() 检查转角与速率，按钮只接受取消或释放，且取消需有先前巡航接合状态。其部分 RX 项显式忽略校验和与计数器，不能泛称全链路完整性校验。驾驶员 EPS 扭矩分别用于软覆盖与硬退出。

    MG 走扭矩转向：CarController.update() 每两帧按驾驶员施力与变化率对期望扭矩限幅，未激活时置零，只构造 LKAS 转向帧；mg_tx_hook() 的 TX 白名单仅一条转向帧，固件再次检查最大扭矩、速率、实时变化与驾驶员扭矩。其安全注册只在调试编译中。

    平台 输入来源 输出与固件门
    BYD 动力总线取速度、转角、扭矩、踏板、车门；相机总线取 ACC 与原 LKAS HUD 车辆模型限幅转角；TX 检查转角与速率，按钮只接受取消/释放
    MG 状态来自 PT 与相机两路，含巡航故障与临时转向故障 每两帧限幅扭矩、未激活置零；TX 仅一条转向帧并复检扭矩/速率

    PSA 与 mock：EPS 重使能与未知车型回退

    PSA 设转角控制与 dashcamOnly=True，主、ADAS、相机三总线共同提供速度、驾驶员与 EPS 状态、巡航、制动与安全带。CarController.update() 每五帧做转角限幅并发 LKAS；在 EPS 覆盖后按 READY 到 AUTHORIZED 再到 ACTIVE 的状态序列尝试重使能，实际策略必须在目标平台验证。psa_tx_hook() 的白名单只含 LKAS 转角帧，并限制目标角度与速度相关变化率；部分 RX 项忽略校验与计数。

    mock 是明确的隔离边界：_get_params() 设 dashcamOnly=True，CarState.update() 返回空状态，CarController.update() 返回空 CAN 列表。get_car() 在无法识别车型时回退到它，被动路径还会把安全配置设为 noOutput。因此 mock 可用于只读、仿真与未知车型隔离，不能用来推定车辆控制可用。

    对硬件与插件化的含义

    插件清单必须区分 notCar、dashcamOnly、发布与调试固件注册状态、控制语义和总线拓扑；加载实现并不等于允许执行。车型控制插件只能产出候选帧，独立安全 MCU 仍需按车型验证 RX 有效性、TX 白名单与转角或扭矩限制。body 的刷写例外不能进入乘用车固件。

    BYD 的相机 HUD 保留、PSA 的 EPS 重使能状态机及各平台的巡航接合语义，都应放入明确的能力与风险契约，不能抽成无条件的通用按钮或转向插件。相关测试入口包括 body、BYD、MG、PSA 的专项测试与通用车型接口测试，本次只确认文件存在，未运行也未验证实车行为。

    常见问题

    body 是乘用车平台吗？

    不是。body 是开发平台，其接口设置 notCar=True，执行方式是双轮差速与速度控制，代码还明确注明加速度字段并非真实加速度语义。它的固件安全策略不能移植到乘用车。

    dashcamOnly 与调试注册意味着什么？

    意味着这些路径在固定快照中不作为发布可用功能。BYD、MG、PSA 都设了 dashcamOnly=True，其 panda 安全模式只在 ALLOW_DEBUG 下注册，因此不能把代码路径解读为发布固件可用功能。

    mock 会不会真的发控制帧？

    不会。mock 的 CarState.update() 返回空状态，CarController.update() 返回空 CAN 列表，被动路径还把安全配置设为 noOutput。它用于只读、仿真与未知车型隔离，不能用来推定车辆控制可用。

    插件加载了某平台实现就代表可以执行控制吗？

    不代表。插件清单要区分 notCar、dashcamOnly、发布或调试固件注册状态与控制语义；加载实现不等于允许执行，最终 TX 仍由独立安全 MCU 按车型校验。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/OTHER_PLATFORMS_DEEP_DIVE.md（取用了 body/BYD/MG/PSA/mock 五平台的参数、输入、输出与固件事实，以及插件化含义）。
    • 项目 02 —— openpilot-research/BYD_PANDA_SAFETY_MODE_DEEP_DIVE.md（关联的 BYD Atto 3 safety 专题，用于补充转角链与按钮门细节，本文未展开其探针）。

    说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • 17 个品牌参数怎么构建：CarParams 冻结只到顶层，嵌套字典仍可变

    结论：车型参数不是一张静态表，而是「17 个品牌枚举 → PLATFORMS 候选字典 → CarSpecs 尺寸 + PlatformConfig 文档与 DBC → 品牌 _get_params() 覆写」的多段构建结果。冻结（freeze）只作用于配置对象这一层：flags 被锁定后不可改，但嵌套的 dbc_dict 与 car_docs 仍可原地修改，override() 返回的还是未冻结副本。因此「能生成 CarParams」只说明字典装载成功，既不等于该车型被识别，也不等于控制器获准发送。以下为固定源码快照 c8fb906 的静态结构分析。

    参数构建的顺序与产物

    values.py 汇集 17 个品牌的 CAR 枚举，并生成候选名到平台对象的 PLATFORMS 字典。每个平台带着三样东西：描述整车尺寸的 CarSpecs、记录文档与 DBC 映射的 PlatformConfig，以及一组 flags。枚举构造时给配置填 platform_str 并冻结配置对象；CarSpecs 本身是 frozen dataclass。

    真正把参数拼起来的是两段函数。get_std_params() 先写入车型名、横向最大加速度文档值、控制类型、轮速系数、PCM 巡航与纵向缺省；随后 get_params() 复制平台规格并调用品牌 _get_params()。这个钩子可以依据 CAN 指纹、固件、开发/发布模式设置总线、雷达、纵向与控制调参，是品牌策略的主要落点。

    品牌覆写之后，普通汽车会加 STD_CARGO_KG=136 kg，再按以 Civic 为基准的比例公式估计 rotationalInertia 与 tireStiffnessFront/Rear；notCar 跳过载荷。这里要强调：刚度与惯量是启发式缩放，不是本次车辆的在线辨识结果，自制硬件接入车型时这些动力学参数不保证准确。

    阶段 入口 产出或作用
    平台注册 values.py / PLATFORMS 17 个品牌候选名映射到平台对象与 PlatformConfig。
    共同缺省 get_std_params() 写入车型名、控制类型、轮速系数、巡航与纵向缺省。
    品牌覆写 品牌 _get_params() 按指纹/固件/模式设置总线、雷达、纵向、panda 安全配置。
    载荷与动力学 STD_CARGO_KG 与缩放公式 非 notCar 加 136 kg，估计转动惯量与轮胎刚度。

    冻结边界：顶层不可变，嵌套仍可变

    隔离探针确认了一个容易被误读的边界：创建 Platforms 子枚举时，PlatformsType.__new__() 给配置写入平台名并冻结，随后直接改 flags 会抛异常；但 dbc_dict 的条目与 car_docs 列表仍可原地修改。

    更关键的是 override() 的语义。对已冻结配置调用 override(flags=...) 会通过 dataclasses.replace() 产生一个未冻结的新对象，且新旧配置共用同一 dbc_dict 引用；相对地，CarSpecs.override() 返回的新规格仍是 frozen dataclass。也就是说，「冻结的是配置对象属性」不能被误解为整个嵌套对象图都经过不可变性与签名校验。自制插件若用 manifest 描述车型，需把嵌套映射与列表做不可变快照或深拷贝并纳入签名与哈希，不能只依赖顶层 freeze()。

    扭矩数据与横向回调

    横向能力由三份 TOML 与一组回调共同决定。get_torque_params() 读取 substitute.toml、params.toml、override.toml，以 legend 解释三列数值，结果缓存在进程内；同一候选若直接出现在多个 TOML 会抛异常，替代目标则按 override 优先、params 次之取值。configure_torque_tune() 设置 FRICTION、LAT_ACCEL_FACTOR、零 offset 与角度死区。

    缺省前馈 get_steer_feedforward_default() 约为目标转角乘车速平方，GM 等品牌可重写。缺省的 torque_from_lateral_accel_linear() 与 lateral_accel_from_torque_linear() 按 latAccelFactor 正反映射，品牌同样可替换。要注意 MAX_LAT_ACCEL_MEASURED 用于 CarParams.maxLateralAccel，而摩擦与侧向加速度因子进入扭矩调参，三者不能互换。

    源或函数 实际作用 关注点
    get_torque_params() 读取三份 TOML 并缓存结果 同候选出现在多个 TOML 会抛异常；替代目标按 override 优先。
    configure_torque_tune() 设置摩擦、侧向加速度因子、零 offset 与角度死区 数据表与平台覆写共同决定控制器输入，不能假设热改立即生效。
    get_steer_feedforward_default() 缺省前馈约为目标转角乘车速平方 GM 等品牌可重写，不是跨车型通用标定。
    torque_from_lateral_accel_linear() 按 latAccelFactor 正反映射扭矩与侧向加速度 需验证符号、单位、摩擦与零点。

    实例运行契约与基类扩展点

    CarInterfaceBase.__init__() 创建品牌 CarState、其 CANParser 集合与 CarController，并把解析器的 DBC 名传给控制器。update() 更新所有解析器、调用品牌状态函数、汇总 canValid/canTimeout 并处理仪表速度与按键；apply() 委派品牌控制器生成回报与待发 CAN 帧，但它不负责硬件限幅。

    仓储里还有几个常被忽略的基类语义：RadarInterfaceBase.update() 缺省每五次调用返回空雷达数据、其余返回 None；init()/deinit() 供品牌实施 ECU 初始化或恢复，基类为空，且 deinit() 在 card 退出时不保证被调用；get_interface_attr() 动态导入品牌 values/fingerprints 属性，ImportError/OSError 会被静默跳过，因此它并不是可靠的插件装载审计。

    基类接口 职责与边界
    __init__() 创建品牌 CarState、CANParser 与 CarController；DBC 名传给控制器。
    update() 更新解析器、汇总 canValid/canTimeout、处理仪表速度与按键。
    apply() 委派品牌控制器生成回报与待发帧，不负责硬件限幅。
    RadarInterfaceBase.update() 缺省每五次返回空雷达数据，其余返回 None，有雷达平台须覆写。
    init()/deinit() 品牌可实施 ECU 初始化或恢复；deinit() 不保证在 card 退出时被调用。
    get_interface_attr() 动态导入品牌属性，异常静默跳过，非可靠装载审计。

    插件化边界与验证缺口

    面向自制硬件，源文档给出的是一组建议设计而非已实现能力：平台插件以版本化 manifest 声明车型、硬件拓扑、DBC 哈希、固件证据、单位、参数范围与所需安全模式；参数构建拆成纯函数与受限生命周期钩子，_get_params()、init() 不应由普通诊断或 UI 插件获得原始 CAN 发送权；行车期间冻结参数与插件版本，重启后再重新识别与验证。

    同时应区分四个层级的门：「可生成 CarParams」「CANParser 正常」「控制器允许发送」「MCU 允许执行」；任一失败都应退回只读或 noOutput。需要提醒的是，现有测试只覆盖参数基本范围与空 CAN 下的不崩溃行为，不覆盖真实车型识别、DBC 真实性、全部 _get_params() 分支与实车动力学。自研硬件仍需要离线日志、台架与实车的分级验证。

    常见问题

    冻结后的 PlatformConfig 真的完全不能改吗？

    不是。冻结只锁住配置对象属性：flags 不可改会抛异常，但嵌套的 dbc_dict 条目与 car_docs 列表仍可原地修改。override() 还会通过 dataclasses.replace() 生成未冻结新对象，并且新旧配置共用同一 dbc_dict 引用。插件若依赖不可变性，需自行做深拷贝并纳入签名。

    STD_CARGO_KG 是 136 kg 吗，为什么有的车型不加？

    源文档给出 STD_CARGO_KG=136 kg，普通汽车在品牌覆写后加上，notCar 跳过载荷。转动惯量与轮胎刚度也是按以 Civic 为基准的比例公式估计的启发式缩放，不是本次车辆的在线辨识结果。

    get_non_essential_params() 能当作上车参数吗？

    不能。它用空 CAN 指纹、空固件及关闭的特性开关构建参数，自身文档明确警告缺少真实 FW/指纹时控制必需参数可能不完整或错误，适合文档、测试与离线展示，不是上车控制参数的证明。

    同一个候选车型出现在多个扭矩 TOML 会怎样？

    会抛异常。源文档说明：同一候选若直接出现在多个 TOML 会抛异常；被替换的目标则按 override 优先、params 次之取值。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/CAR_PLATFORM_PARAMS_CONTRACT_DEEP_DIVE.md（参数构建顺序、冻结边界、扭矩 TOML 与基类实例契约）。
    • 项目 02 —— openpilot-research/ 同目录探针记录：四项平台配置冻结契约与假平台枚举隔离探针结论。

    说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11