类型服务器协议（TSP）是一个用于请求类型服务器以获取Python分析数据的JSON-RPC协议。类型服务器维护工作区的类型分析状态，并回答关于协议版本、快照、Python搜索路径、导入解析和类型查询（计算类型、声明类型和预期类型）的请求。该协议在有用的地方使用语言服务器协议（LSP）数据形状和约定，例如位置和范围，并且以LSP相同的方式将URI表示为字符串。TSP方法使用typeServer/前缀。本文件夹中的协议文档是权威性的定义：typeServerProtocol.ts定义了TypeScript接口和请求类型。tsp.json是机器可读的协议模型。tsp.schema.json是协议模型的JSON架构。版本历史 TSP使用语义版本字符串进行客户端/服务器兼容性检查。当协议处于0.x行时，次要版本更改可能会导致不兼容。补丁版本更改在同一个次要行内保持向后兼容。版本更改 0.1.0 初始协议版本。 0.2.0 添加了请求类型和字段。 0.3.0 切换到更复杂的类型形状。 0.4.0 切换到类型联合和基于存根的类型负载。 0.4.1 添加了多连接协商和typeServer/connection控制请求。连接模型 客户端启动类型服务器并通过主JSON-RPC连接使用服务器支持的传输与其通信，如stdio或Node IPC。当使用stdio时，stdout必须保留用于JSON-RPC协议消息。预计类型服务器能够接收足够的工作区和文档状态以回答它支持的TSP请求。客户端通常使用正常的LSP初始化和文档同步来满足此状态，然后在同一JSON-RPC连接上发送typeServer/*请求。TSP还支持可选的额外只读连接。原始连接仍然是主连接，并且拥有初始化、工作区状态、文档同步、状态改变通知和连接控制。额外连接仅在客户端和服务器在初始化期间协商支持后打开。启动序列 典型的会话按照以下顺序进行：客户端启动或连接到类型服务器。客户端和服务器初始化任何共享工作区状态，通常通过LSP初始化和已初始化消息。客户端调用typeServer/getSupportedProtocolVersion并验证返回的语义版本字符串与其预期的协议版本兼容。客户端调用typeServer/getSnapshot以获取第一个快照标识符。客户端发送包含当前快照的类型查询、导入解析或搜索路径请求，具体取决于请求形状的需要。当先前的类型结果不再有效时，服务器发送typeServer/snapshotChanged。多连接模式 多连接模式是一种可选的性能特性。它允许客户端为只读TSP请求打开额外的本地通道到同一类型服务器，同时主连接继续拥有可变的工作区状态。客户端应仅在能够从并发的只读工作中受益时使用多连接模式，例如高频率的类型查询或不应阻塞主JSON-RPC连接的后台工作。服务器仍然必须在单连接模式下正常工作。多连接支持不应被视为协议正确性的必要条件。能力握手 多连接支持通过正常的LSP初始化请求和响应进行协商。能够打开额外TSP通道的客户端在capabilities.experimental.typeServerMultiConnection下公布所支持的传输类型： { "capabilities" : { "experimental" : { "typeServerMultiConnection" : { "supportedTransports" : [ " ipc " ] } } } } 能够提供额外TSP通道的服务器在初始化结果中返回相同的能力形状： { "capabilities" : { "experimental" : { "typeServerMultiConnection" : { "supportedTransports" : [ " ipc " ] } } } } 仅当双方都宣传typeServerMultiConnection且两个supportedTransports列表至少有一个传输相同时，多连接模式才会启用。如果任何一方省略了该能力，或者如果没有共同的传输，则会话保持为单连接，并且客户端必须不发送typeServer/connection。目前支持的额外连接的内置传输类型是ipc。此协商与主连接分开，主连接可以使用stdio或Node IPC。打开额外连接 在初始化和传输协商后，客户端通过在主连接上发送typeServer/connection来打开额外通道： { "type" : " open " , "kind" : " ipc " , "args" : [ " <ipc-endpoint> " ] } 对于ipc，args数组标识服务器应连接的端点或端点。