cpp/pl/flux/contrib/lsp 的目标就是让 Flux 从“能执行”走到“能日常编辑”：打开文件时能诊断语法错误，输入 array. 时能补 package 函数，光标放在 lambda 参数上能跳回定义，rename 不会误改 shadowing 变量，semantic tokens 能区分 package、函数、参数和引用。

这一篇不按功能列表平铺，而是从一次编辑器请求开始，看 Flux Language Server 如何把 JSON-RPC、文档同步、AST 缓存、符号表和各类 feature handler 串起来。

一次编辑器请求如何流动

假设用户在编辑器里打开了这样一段 Flux：

import "array"

data = array.from(rows: [{host: "edge-1", usage: 91.2}])

data
    |> filter(fn: (r) => r.usage > 80.0)
    |> keep(columns: ["host", "usage"])

当用户输入 array.、保存文件、或者把光标放到 r.usage 上时，编辑器会通过 LSP 向 server 发请求或通知。server 不能每个功能都自己 parse 一遍，也不能把 completion、diagnostics、definition 写成彼此独立的临时逻辑。它需要一套共享的语言服务基础设施。

接下来真正重要的问题不是“还能加什么功能”，而是“哪些功能能让它从可用走向好用”。

当前已经稳定的主干

语言前端方面，scanner/parser/AST 已经覆盖常见 Flux 查询语法。表达式优先级、函数、pipe、record、array、object、regex、datetime、duration、类型语法都有测试覆盖。

运行时方面，Value、Environment、expression evaluator、statement executor、function closure、pipe 参数、标准库 package 和 table pipeline 已经形成闭环。

查询执行方面，内存 TableValue 路径仍然可用；SQLite/MySQL connector 已经走 metadata/split/page source；optimizer 和 physical executor 主干已经存在；Page streaming、exchange、accumulator 和 profile 能覆盖越来越多真实查询。

工具链方面，CLI、REPL、AST dump、JSON/CSV/human 输出、LSP 和 conformance examples 都已经可用。

路线图的排序原则

后续路线不能只按“哪个功能酷”排序，而要看它是否强化主干。

优先级最高的是会被多个模块共享的基础能力，例如 analyzer/binder、类型诊断、metadata/statistics、Page execution profile、标准库 conformance。这些能力一旦补好，会同时改善 runtime、LSP、optimizer 和文档。

优先级较低的是孤立能力，例如临时加一个外部 IO package、支持某个少见语法糖、或者为一个 demo 写特殊 builtin。它们看起来能快速增加功能列表，但不一定提升项目整体质量。

语言层路线图

最值得补的是语义分析和类型检查。当前很多错误要到 runtime 才暴露，例如参数类型不匹配、函数返回值不符合 builtin 预期、对象字段不存在等。

类型检查不一定要一开始追求完整 Hindley-Milner。更现实的方式是先做 binder：

• 绑定 import、package、builtin、变量和函数。
• 给常见 builtin 建立参数/返回形状。
• 对明显错误给出诊断。
• 为 LSP hover/signatureHelp 提供类型信息。

其次是 formatter。LSP 已经有 formatter 模块，但要达到日常可用，还需要更多真实文件快照和格式风格约束。