调用前先核对客户端登录和本地接口 URL
比特浏览器本地服务指南要求先安装并登录客户端，再到系统设置取得本地接口 URL。准备测试连接时，可以把这两项写在检查单最上方：当前客户端是否已登录，以及接口 URL 是从哪个设置页面读取的。本文不展示某台机器的地址，也不把文档示例地址当作每个人都能直接使用的地址。
比特浏览器官方中文站提供 Windows 与 macOS 客户端入口。若尚未获取客户端，应先到官方中文站核对与你系统对应的入口；若尚未完成登录，就停在准备阶段，回到官方本地服务指南核对使用方式。已登录但没有确认接口 URL 时，也先查系统设置，不要从旧笔记、他人的截图或搜索结果猜测本机地址。记录时只写“已在系统设置确认”或“尚未确认”，不要把含有本机信息的完整地址贴到公开页面。
这一节只解决调用前的资料和状态核对。它不能证明本地服务已经连通，更不能说明某个业务接口一定可用。完成客户端与 URL 两项后，再单独阅读官方健康检查接口说明；若实际界面和文档不同，以当前官方文档及设备界面为准。
用官方 POST /health 定位连接检查这一步
比特浏览器的浏览器接口文档把 POST /health 标为健康检查接口，用于测试 Local Server 是否连接成功。查资料时，先确认自己打开的是官方浏览器接口页，并核对请求方法为 POST、路径为 /health。这个检查目标是本地服务连接；它和创建、修改或打开窗口等业务操作不是同一件事。
本文只建议依照官方接口页核对方法、路径与用途，不提供替代官方示例的完整请求，也不预设你的本地 URL、端口或脚本环境。把“地址已确认”“POST /health 已按文档核对”“结果仍需确认”分开记录，能避免把尚未验证的配置写成连通结论。具体请求细节继续以该页现行说明为准。
如果这一步没有得到你预期的结果，先回看上一节的客户端登录与系统设置，而不是马上修改业务接口参数。反过来，连接检查符合预期也只说明你可以继续检查业务请求；它不能替后续接口参数、权限或返回结果作保证。
业务请求的参数位置与 JSON 格式分开核对
比特浏览器本地服务指南说明，本地 API 接口使用 POST 请求，并以请求体传参。比特浏览器 API 常见问题说明，本地 API 参数应以 JSON 请求体传递，不接受 URL 参数、formdata 或字符串。两份资料分别回答“请求怎样发”和“参数怎样组织”。准备业务调用时，把方法、参数位置和格式列成三项逐个核对。
例如排查“传参格式不对”时，先看自己有没有把参数误放到 URL，再看是不是使用了 formdata 或纯字符串，最后对照对应业务接口文档检查具体字段。本文不列出未经逐项核验的窗口参数，也不建议为试通请求而任意删掉字段或改成别的类型。健康检查与业务调用应分开记录，避免把 /health 的用途当成所有接口的参数示例。
查阅顺序可以是：先读官方接口定义，再在自己的受控环境核对请求，最后把已确认的格式写入脚本。若还不知道某个字段的含义，先在相应接口说明里查清，不要为让请求通过而猜测取值。不要在公开求助内容中粘贴账号信息、完整本地接口 URL 或实际业务数据。
按 success、data、msg 阅读业务接口结果
比特浏览器本地服务指南说明，业务接口返回 JSON 对象：success 为 true 表示业务成功；有返回数据时可附在 data 中；success 为 false 时，失败信息附在 msg 中。读响应时，可以先看 success，再根据其状态查看 data 或 msg，而不要只看到 HTTP 层面的结果就推断业务已完成。
这组字段来自官方本地服务概述。本文没有证据认为 POST /health 一定返回同样的 success、data、msg 结构，因此不要拿业务返回字段去解释健康检查的每一种结果。分别记录“健康检查的观察结果”和“某个业务接口的返回字段”，会让后续排查更清楚。
当 msg 提示参数问题时，回到该接口自己的字段定义核对名称、类型和含义。若 data 没有出现，也先对照官方文档看当前接口是否本来就会返回数据。这里只给阅读顺序，不代替具体接口的返回规范，更不保证任何脚本在所有客户端状态下都得到同样内容。
窗口接口报参数问题时回到字段定义
比特浏览器 API 常见问题提醒，创建或修改窗口等调用要遵守参数规范，不要随意删改参数，也不要传入未知意义的值或类型。因此当业务调用出现问题时，先定位自己调用的具体接口，再查官方页面上的字段要求，而不是复制别的窗口操作请求直接改几个值。
可以按“接口名称、参数位置、字段类型、字段含义”四栏记录已核对内容。先把官方文档明示的要求填上；没有在原文中确认的字段则留空。若调试工具显示发送的是 formdata、URL 参数或字符串，先回到格式检查；若格式无误但业务结果提示失败，再检查该接口的字段定义。
本文不提供会改动真实窗口的演示参数，也不声称某一条错误提示一定对应同一种原因。保留请求类型和错误表现的简要记录即可；涉及账号、代理或窗口数据时，分享给他人之前先移除敏感内容。
把连接、格式与业务结果写成三行检查单
最终可用三行检查单收束问题。第一行是准备条件：客户端已安装并登录，且本地接口 URL 已从系统设置核对。第二行是连通性：已按官方文档确认 POST /health 的方法和路径。第三行是业务调用：POST 请求、body 中的 JSON 参数，以及返回对象里的 success、data、msg。每一行只填自己真正核对过的内容。
若第一行尚未确认，就回到官方本地服务指南；第二行有疑问，就读浏览器接口页的健康检查小节；第三行遇到格式或字段问题，就分别对照 API 常见问题与具体业务接口说明。这样能把“本地服务连不上”“参数放错位置”“业务返回失败”分成不同待查事项，而不把它们解释为同一个故障。
读完后保留下一步：打开与你未确认的那一行对应的官方页面。本站只是整理查阅顺序，不托管客户端安装包，也没有读取你的设备状态。涉及版本、接口字段或界面位置的实际变化，以比特浏览器当前官方页面为准。