车辆列表 carList
提供车型身份和车辆属性：openStatus、modelType、remoteFlg、sfx、carSeries、sharedFunction。
菜单字段诊断器
从“全量按钮”一步步筛到用户最终看到的菜单。
这页关联 Obsidian 笔记《车控菜单字段筛选逻辑详解》，把 carList、后端配置、个性化、 本地 sfx 表、DCM 契约这些字段放进同一条筛选流水线。重点训练一个能力： 看到某个按钮显示、隐藏、置灰时，能快速说清它是被哪一关决定的。
先找字段从哪来
车控菜单由 5 个数据源共同决定。
不要只盯一个接口。最终菜单是车辆主数据、后端能力、本地 sfx、个性化、契约状态合并后的结果。
后端功能配置
getCarFunctionConfig 决定空调、数字钥匙、服务可用性等动态能力。
个性化接口
getPersonalizationByVin 返回 result=1 时，个性化设置才有资格展示。
本地 sfx 能力表
remote_control_local.json 按 sfx 映射门锁、尾门、双闪、蜂鸣器、喇叭等硬件能力。
DCM/DK 契约
契约接口派生 isDcmExpired、isDkAvailable，决定置灰和数字钥匙可用性。
筛选流水线
7 道关卡：先定菜单基座，再逐层过滤。
按钮缺失时，先判断它死在哪一关。置灰是最后的可用性判断，不等于按钮应该隐藏。
按钮诊断器
点一个按钮，看它完整经过哪些字段条件。
这部分适合排查“为什么这个按钮没有/为什么只有某些人能看见”。
实战场景
把字段条件放回业务场景里推导。
同样是菜单少按钮，可能是低配路线、共享权限、sfx 硬件差异、契约置灰，或者 BTET 分叉。
字段速查
按来源或用途查字段，不要孤立背字段。
搜索字段名、来源、按钮或含义，快速定位它控制哪一层。
记忆口径
把复杂筛选压成 6 句排查语言。
以后遇到菜单问题，就按这个顺序提问。
is24Dcm、modelType、remoteFlg、carSeries 先决定菜单基座。
hasControl 管控车，hasLocation 管地图寻车，limitedCarInfoEntity 管 DK。
门锁、尾门、双闪、蜂鸣器、喇叭等，先查本地 sfx 能力表。
空调变体、数字钥匙、个性化设置等，要看后端能力和接口返回。
DCM 过期或个人车未实名，通常是按钮保留但 alpha=0.4、点击拦截。
八宫格只是渲染层，前面字段筛完才知道用户会看到哪些按钮。
一句话：
菜单显示 = 车型基座 - 共享权限过滤 - sfx 硬件过滤 - 后端能力过滤 - 车辆属性过滤，再叠加文案适配和置灰状态。