点数上限因设备代际和价位差异很大，不能假设统一支持数
别名: 设备差异 · 十点假设 · 触点能力碎片
概念解释
“当代触屏都是十点”是假的。同一品牌里，旗舰手机、入门平板、车机中控和投屏显示器的同时触点上限可以差到两倍以上。应用若按开发者手机的十指写死三指手势和四人白板，会在另一台合法上市的设备上静默少指。上限是设备能力，必须查询或探测，不能当平台常量。
机制
触控 IC 按 BOM 成本选槽位数和扫描频率；低价方案用更少的通道和更弱的 MCU，峰值跟踪数先被砍。操作系统再按产品形态裁一刀：有的平板为了和笔记本模式共用驱动，把上报上限收到五；有的电视触控框只保证两指缩放。WebView、远程桌面和投屏接收端还会再夹一层，把源设备的十点收成接收端的两到五点。代际升级也不单调：新机为了省电或为了给触控笔留槽，应用可见的手指上限可能比上一代更小。开发者用自己的机器测一次，看到的是那一颗 IC 的数，不是产品矩阵的数。
怎么研究
在要支持的机型矩阵上跑同一套逐步加指脚本，列出每台机器的实测上限、系统版本和是否外接触控。自变量是机型档位、是否接笔、是否投屏/镜像、以及浏览器 vs 原生。因变量是可跟踪 id 数、三指手势成功率、以及文档里的标称值与实测值之差。把“API 查询到的最大值”和“真正能同时报点的数量”分开：有的系统接口返回 10，第五指已经开始丢。覆盖至少一档入门机和一档车机或教育平板，否则矩阵会被旗舰采样偏差吞掉。
边界
若产品只跑在单一锁定硬件（专用展项、单一 SKU 的工控屏），统一假设成立，探测代码是多余的。操作系统提供的查询 API 若被 OEM 填成假数字，查询本身不可信，仍要运行时探测。模拟器和云真机农场常常模拟成 10，和入门真机不符。把 Android 与 iOS 的“平台默认上限”写进跨端框架，会在 Linux 桌面触控和 Harmony 设备上直接错。
怎么落地
- 启动时用逐步加指或系统能力查询得到本机上限，三指以上的手势在上限不足时改成可见按钮，不要等用户自己发现。
- 兼容性矩阵按入门机、旗舰、平板、车机、投屏各测一档，手势文档写“最低需要 N 个同时触点”，而不是“支持多点触控”。
- 远程桌面和投屏模式单独测一遍接收端上限，源端手势在对端变两指时要有降级。