结论：把 Car Scanner 的同类产品按「从车到手机的数据链」拆开，市场自然分成四层：通用适配器应用、车型深度应用、专用硬件配套应用、专业相邻产品。在一份已记录 1295 项软件商品/项目的市场地图里，证据等级 A 有 824 项、B 有 467 项（另有 4 项按功能分层标注 A/B）。条目数量只代表「已记录规模」，不代表全球市场总量，也不代表全部功能已实测。
四层分类：从通用适配器到专业相邻
分类的判据不是价格，也不是品牌知名度，而是数据链的接入方式与扩展方向。四层各有一批代表产品：
| 层 | 典型链路 | 代表产品 |
|---|---|---|
| 通用适配器应用 | 用户自选 ELM327 兼容适配器 → App → 标准 PID/DTC、仪表、日志 | OBD Fusion、OBD Auto Doctor、EOBD Facile、inCarDoc、MotorData OBD、DashCommand、Torque、hobDrive |
| 车型深度应用 | 受支持适配器 → 特定车系厂商协议诊断与编码 | FORScan Lite、OBD JScan、BimmerLink、BimmerCode、Carista、OBDeleven、Carly、AlfaOBD |
| 专用硬件配套应用 | 自有扫描器 → 诊断、报告、保养操作 | OBDLink、BlueDriver、FIXD、RepairSolutions2、ThinkDiag+、TOPDON CarPal、Autel MaxiAP 系列、Launch EasyDiag4、Xtool Anyscan |
| 专业相邻产品 | 专用硬件 + 浏览器外壳，向专业诊断延伸 | VCDS-Mobile（Ross-Tech） |
四层之间不是升级关系，而是口径差异：通用层把兼容性风险交给用户，车型层靠协议深度换口碑，硬件层把连接质量收敛到自家设备，专业相邻层则把车型知识与 VIN 授权做成更厚的壁垒。做竞品对照时，先确定比较对象属于哪一层，否则很容易把「通用 App 的价格」和「专用设备的授权」放在一张表里比。
证据等级：A / B / C 分别意味着什么
市场地图对每条记录标注证据等级，它衡量的是公开材料的交叉程度，而不是产品好坏：
| 等级 | 判定依据 | 能说明什么 |
|---|---|---|
| A | 官网和商店相互印证，或公开源码与项目说明交叉核验 | 公开证据可交叉，仍不等于已在量产车辆上验证 |
| B | 商店描述或官网单一来源 | 仅有厂商自述，未获第二来源 |
| C | 待核验候选 | 证据不足，暂不作为已确认产品 |
需要反复强调的是：商店描述是厂商自述，不能证明实际车型覆盖、功能质量或收入规模；应用商店所列的开发者/销售主体，也不自动等于集团最终控股公司。
规模与边界：1295 项条目到底在数什么
这份清单当前列有 1295 项软件商品/项目，其中证据栏为 A 的 824 项、B 的 467 项，另有按功能分层标注 A/B 的 4 项。这个口径包含 Car Scanner 基准产品、依赖主程序的诊断包、配套后端及公开源码工具、历史教学原型，以及相邻的非 OBD 传感器诊断工具。
因此那句话必须说清楚：此数量是报告已记录条目的规模，不代表全球市场总量、全部功能均已实测，也不代表独立运行应用的总数。 类似地，逐关键词的搜索窗口（例如某地区一次检索返回若干 App ID）只是候选窗口，不能被当作地区市场穷尽。
六问维度与三种扩展路径
每款产品按六个问题分析：数据如何从车到手机；连接兼容范围；故障读取/清除、实时数据、记录与报告；厂商扩展、编码和保养操作；用户付费与硬件绑定；对 Car Scanner 的竞争压力。把这六问的结果横向看，会得到三条清晰的扩展路径：
| 扩展路径 | 做法 | 代表产品 |
|---|---|---|
| 加深度：仪表与记录 | 把实时数据的可视化、仪表盘与记录做厚 | OBD Fusion、DashCommand |
| 加闭环：故障解释与维修 | 把「发现问题」接到「怎么修」 | FIXD、BlueDriver、Innova |
| 加权限：车型协议与可写操作 | 进入车型专有协议、编码与保养操作 | FORScan、OBDeleven、BimmerLink |
与三条路径并行的，是两类锁定：自有扫描器降低连接风险、但提高用户换工具的成本；车型授权或订阅换取持续更新资金、但需要清晰展示有效车型和权限。这两类锁定的共同后果是——付费口径必须按「设备 + 车型 + 权限」三层分别核对，不能只看一次下载价格。
值得追问的三件事
- 共同底座不能自动延伸。连接管理、车辆识别、OBD2 请求/响应、DTC 词库、实时数据可视化、会话记录与导出，是几乎所有产品的共同底座；但通用标准能做的跨品牌入口，不能自动延伸成全车模块诊断。
- 产品页只能证明厂商宣称。决定性验证是同一辆车、同一适配器上比较连接时间、可读 ECU、PID 更新频率、DTC 解释质量、报告、编码安全与付费墙。
- 尚未覆盖的市场要如实标注。源文档明确列出：Android 商店的完整长尾和中国第三方 Android 商店、OEM 原厂售后工具与维修厂级 PC 平台、商用车/重卡诊断长尾及车队远程信息处理；公司营收、用户数、市场份额、车型真实覆盖率与适配器连接成功率因缺少统一可验证的一手样本，不据营销数字排名。
常见问题
1295 项是不是 OBD App 的市场总量？
不是。这是市场地图已记录条目的规模，包含基准产品、诊断包、配套后端、公开源码工具与教学原型等；源文档明确它不代表全球市场总量，也不代表全部功能已实测或独立运行应用总数。
证据等级 A 是否代表产品已经过实车验证？
不代表。A 的判定依据是「官网和商店相互印证，或公开源码与项目说明交叉核验」，衡量的是公开材料的交叉程度；商店描述是厂商自述，不能证明实际车型覆盖、功能质量或收入规模。
Car Scanner 最该防的是哪一类竞品？
不能用单一答案概括，因为四层对应不同的竞争压力：通用层的 OBD Fusion、IncarDoc 等争夺低成本适配器用户；车型层靠协议深度形成壁垒；硬件层收敛连接质量；专业相邻层以车型知识与 VIN 授权加厚壁垒。源文档的建议是先确定比较对象属于哪一层，再按六问维度逐项对照。
要不要按厂商公布的「支持多少品牌」来排名？
不建议。源文档把「公司营收、用户数、市场份额、车型真实覆盖率与适配器连接成功率」明确列为缺少统一可验证一手样本的项，不据营销数字排名。同一页面上的「39 品牌」「120+ 品牌」「98% 车型」也不应被当作同一覆盖指标。
延伸阅读
- 竞品功能点数据库：怎么量化 Car Scanner 的字段覆盖度 —— 承接本文「六问维度」的量化方法。
- 226 个功能点拆成 20 个模块：一款 OBD App 的能力地图 —— 把产品能力拆成可比模块的另一视角。
- 仪表市场对照：ScanGauge / Beeline / CHIGEE / Wahoo / Karoo —— 相邻硬件仪表层的横向对照。
- OBD AI 插件化平台：端侧解析为什么必须插件化 —— 承接扩展路径中「加权限」与插件化的关系。
- 84% 的 PID 没有公开证据：OBD 私有协议解析的现实边界 —— 解释车型深度层为何难以用公开材料完全验证。
参考资料
- 项目 01 ——
car-scanner-research/市场地图.md（仅取用市场层面：四层分类、A/B/C 证据等级、1295 项规模口径、六问维度与尚未覆盖的市场）。 - 项目 01 ——
car-scanner-research/逐产品拆解.md（仅取用市场层面：四层产品归类、三种扩展路径与两类锁定；未引用任何逆向细节）。
说明：本文仅取用公开市场资料的分类与证据等级口径，未安装任何安装包、未进行通信抓包、未连接车辆，也未核验各产品宣称的车型覆盖与付费权益。文中所有分类、数量与等级判定均出自源文档，标注为未验证的结论保留其原有边界。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复