账号分享 / 车辆分享
看 sharedFunction
用于判断被授权人对这辆共享车有没有远程控车、有没有地图寻车。
hasControl控制车门、尾门、双闪、空调等控车按钮。hasLocation控制地图寻车。- 接受后共享车会进入车辆列表，带分享标签。
先记这个
两个分享体系，两套字段，两条查询线。
账号分享给“远控/定位权限”；数字钥匙分享给“钥匙能力”。它们可以同时存在，但不能互相推断。
数字钥匙分享 / DK 分享
看 limitedCarInfoEntity
用于判断被授权人有没有数字钥匙实体授权，以及具体 DK 子权限。
issueId、remoteItems、shareStatus是 DK 关键字段。- 接受后要初始化 DK SDK 并下载钥匙。
limitedCarInfoEntity=null的共享车不应显示 DK 能力。
绑车与 bindStatus
有没有绑车，先查车辆列表。
进入车控前，系统必须先拿到当前用户的车辆列表和默认 VIN。
用户登录成功、启动 App 或切到爱车 Tab 后触发车辆列表加载。
GET /ftms-iov-app-user/app/userbindcar/carList 返回车辆数组。
bindStatus=1 且 selected=true/1 的车会成为当前默认车。
后续 openStatus、remoteFlg、配置、契约、分享权限都围绕这个 VIN 继续查。
| bindStatus | 含义 | 页面处理 | 排查重点 |
|---|---|---|---|
1 | 已绑定 | 可以进入后续车型路由和车控检查 | 继续看 selected、openStatus、remoteFlg |
2 | 已删除 | 不应按正常车控展示 | 解释为车辆绑定状态异常或已移除 |
3 | 绑定中/人工审核 | 提示审核中或等待 | 不是车控菜单缺陷 |
补充：
HarmonyOS 文档里也能看到
/ftms-iov-app-mycar/v2/user/bindcar/getCarList 这类车辆列表入口。学习时不要纠结路径差异，核心是“车辆列表返回 bindStatus、modelType、remoteFlg、sharedFunction、limitedCarInfoEntity 等主数据”。
remoteFlg
它是远控能力路由标记，不等于 openStatus。
remoteFlg 来自车辆列表，也会在 getOpenStatusByVinV2 中刷新。它决定走低配、普通远控，还是支持 DK 代客的路线。
| remoteFlg | 学习口径 | 会走什么路线 | 典型表现 |
|---|---|---|---|
0 |
不可用/低配 | 低配车型路线 | 不展示完整控车按钮，通常仅保留个性化设置、车家互联等少量入口。 |
1 |
可用/高配 | 普通远控路线 | 进入传统高配菜单，再由 sfx、后端配置、分享权限继续过滤按钮。 |
2 |
支持 DK 代客 | 普通远控 + DK 代客能力 | 在 modelType=1 且 dkey.availability=1 时，可进入代客服务链路。 |
不要混淆：
openStatus=2 说明互联服务已开通；remoteFlg 说明这辆车的远控能力路线。两者都重要，但不是同一个问题。
学习问答
逐条回答你刚才问的点。
下面这些回答可以直接当成排查口径使用。
sharedFunction 是接口吗？它作用是什么？
它不是一个单独接口名，而是车辆列表模型里的权限对象。它通常出现在“当前用户视角下的共享车数据”中， 表示这个被授权人对这辆车有没有控车权限和定位权限。
车主发起分享时提交的是分享权限参数；被授权人接受后，车辆列表里的共享车会带上 sharedFunction，
客户端用它过滤菜单。所以它更偏“被分享端/当前登录用户视角的车辆权限字段”，不是车主自己那辆车的常规能力字段。
如何查询有没有绑车？bindStatus 怎么查？
查车辆列表：GET /ftms-iov-app-user/app/userbindcar/carList。返回数组里看 bindStatus 和 selected。
bindStatus=1 表示已绑定；2 表示已删除；3 表示绑定中/人工审核。
如果没有 bindStatus=1 且被选中的车，就不要继续判断车控菜单，应先进入绑车或审核状态解释。
modelType 有哪些类型？
modelType=0 通常按普通非车联网车型处理，不进入互联车控；modelType=1 是车联网车型，才继续看 remoteFlg、carSeries、sfx、openStatus 等后续判断。
remoteFlg 有几类，分别干什么？
0：低配/不可用，通常不展示完整控车菜单；1：普通高配远控路线；2：在普通远控基础上支持 DK 代客能力。
DK 代客和 DK 分享有什么区别？
DK 分享是把数字钥匙授权给另一个用户，走 addLimitedCarInfo/searchLimitedCarInfoList/updateLimitedCarInfo 这条线；
DK 代客是车主临时授权他人使用车辆，通常要求 modelType=1、remoteFlg=2、dkey.availability=1，
通过 getAuthorizeCodeFromIngeek 拿授权码并打开代客 H5。
operateType=0、1、2、3 是什么？
0：授权人解除授权，车主操作。1：被授权人归还授权，被分享人操作。2：被授权人接受使用权限。3：被授权人放弃使用权限。
查询邀请状态怎么查？
账号分享邀请查 pushCarInfosToSharedPerson；DK 分享邀请查 searchLimitedCarInfoList 且 shareStatus=0。
所以“有没有被分享到车辆控制”和“有没有被分享到数字钥匙”不是同一个查询。
limitedCarInfoEntity=null 说明什么？
对共享车来说，它说明当前用户没有这辆车的 DK 实体授权。即使 sharedFunction.hasControl=1 能显示控车按钮，
也不应该显示数字钥匙入口。账号分享不能自动推出 DK 分享。
业务场景
被授权人能控车，但没有数字钥匙。
这是最容易混的场景：账号分享已经生效，但 DK 分享没有生效。
先查账号分享
车辆列表或共享车数据里有 sharedFunction.hasControl=1，所以锁门、空调、双闪等远控按钮可以显示。
再查 DK 分享
看 limitedCarInfoEntity 是否存在，或者查 searchLimitedCarInfoList 里是否有已接受 DK 分享记录。
null 就不显示 DK
limitedCarInfoEntity=null 表示没有数字钥匙实体授权，不应该显示数字钥匙入口。
结论
“能控车但没有数字钥匙”不是矛盾：账号分享和 DK 分享是两套权限，必须分别查询、分别判断。
一句话记忆：
sharedFunction 决定“能不能远控/定位”；limitedCarInfoEntity 决定“有没有数字钥匙”。