uni-app中百度地图路径规划需调用百度SDK的DrivingRoute/WalkingRoute，且“搜地点”与“规划路线”必须分步执行；数据格式需转换为uni-app 组件支持的[{longitude,lat}]结构，并手动设置color/width；三端初始化方式、参数要求及坐标系（WGS84→BD09）转换均不同，任一环节遗漏将导致路线不显示。
uni-app 里做百度地图路径规划，不能靠 <map></map> 组件自带能力硬撑，必须走百度 SDK 的 DrivingRoute 或 WalkingRoute；而「搜地点 + 规划路线」这两个动作必须拆开调用，否则在 H5 小程序 App 三端都会出问题——比如小程序里明明拿到数据了，地图上就是不画线。
为什么 drivingRoute.search() 返回了数据却没显示路线
这是最常被卡住的点：控制台能打印出完整路线数组，<map></map> 上却空空如也。根本原因不是 API 调用失败，而是数据格式不匹配。
- 百度 SDK 返回的路径点结构是
{point: {lng: 116.397, lat: 39.908}}数组，uni-app 原生<map></map>组件只认[{longitude: 116.397, latitude: 39.908}] - 颜色、宽度等样式字段不能用百度的
strokeColor，得手动塞进polyline对象的color和width字段里 - 小程序端不支持直接渲染百度 SDK 的
Polyline实例，必须转成原生格式再赋值给<map></map>的polyline属性 - iOS App 端若未在
info.plist中声明NSLocationWhenInUseUsageDescription，uni.getLocation会静默失败，导致起点为空
三端调用 DrivingRoute 的关键差异
同一个 DrivingRoute 类，在不同平台初始化方式和参数要求完全不同，混用必报 undefined is not a function。
百度文档解析vlm-parser
下载
调用百度PaddleOCR‑VL大模型API，支持PDF、Word、PPT、图片等多格式文档解析，精准识别印刷体、手写体、表格、公式、图表、印章等复杂元素，支持100+语言，可处理不规则布局和跨页长文档。触发词：文档解析、VLM解析、大模型OCR、PaddleOCR、多模态文档、手写识别、公式识别、复杂版面。
- H5 端需先加载百度 JS API（
https://api.map.baidu.com/api?v=3.0&ak=xxx），再 newBMapGL.DrivingRoute，且必须用 HTTPS，否则 network 面板可见 403，但控制台无提示 - 微信小程序端要用插件市场里的
uni-baidu-map，它封装了wx.navigateToMiniProgram的调用逻辑，search()参数必须带from和to字符串地址，不支持坐标直传 - App 端（Android/iOS）依赖
@dcloudio/uni-plugin-baidu-map，search()接收的是{latitude, longitude}对象，且起点终点必须都传，缺一不可
坐标系不转换，路线永远偏移 300 米以上
手机 GPS 获取的是 WGS84 坐标，百度地图用的是 BD09，高德用 GCJ02——三者之间不转换，哪怕参数全对、API 调通，画出来的路线也会漂在空中。
- 从
uni.getLocation({type: 'wgs84'})拿到原始坐标后，必须调用百度官方提供的coordTrans工具或自己封装的wgs84ToBd09函数转成 BD09 才能喂给DrivingRoute - 如果目标是跳转到百度地图 App 导航（用
baidumap://map/direction），则无需转换，因为 URL Scheme 内部已处理；但如果是页面内绘制路线，就必须转 - 很多项目线上出问题，就卡在「测试时用模拟器坐标是 GCJ02，上线真机却是 WGS84」这个细节上，建议所有坐标入口统一加断言校验
真正难的不是写几行 search()，而是每一步都要问一句：这行代码在 H5 / 微信小程序 / App 三个环境里，分别依赖什么、接受什么、返回什么、哪里会静默失败。坐标转换、数据格式、平台 API 封装层级，这三个点漏掉任何一个，路径规划就只是个看起来能跑的 demo。
