webstorm需手动配置才能启用flow类型检查：必须安装flow cli、设置正确的flow路径和.config文件路径、启用语言服务，并在js文件首行添加// @flow注释且匹配.include规则，否则仅语法高亮不报错。
WebStorm 能直接运行 Flow 类型检查，但默认不启用，必须手动配好 .flowconfig 和语言服务开关，否则只高亮不报错。
确认 Flow CLI 已全局或项目级安装
WebStorm 不自带 Flow，它依赖你本地的 flow 可执行文件。运行 flow --version 能输出版本号才算就位。
- 推荐用
yarn global add flow-bin或npm install -D flow-bin（后者需在 WebStorm 中指定 node_modules/.bin/flow 路径） - 若用 pnpm，注意
pnpm exec flow --version可能成功，但 WebStorm 不支持自动解析 pnpm exec，得手动填完整路径如./node_modules/.pnpm/flow-bin@.../node_modules/flow-bin/cli.js - Windows 用户遇到
'flow' is not recognized，别只改系统 PATH，要在 WebStorm 的Settings > Languages & Frameworks > JavaScript > Flow里显式指定可执行文件路径
在 Settings 中启用 Flow 服务并指向配置文件
WebStorm 的 Flow 支持本质是调用 CLI 启动一个后台 server，不是每次保存都重跑 —— 这个机制依赖正确识别 .flowconfig 位置。
- 进
Settings > Languages & Frameworks > JavaScript > Flow - 勾选
Enable Flow language service -
Flow path填你本地的flow可执行文件（见上一条） -
Config file path必须设为项目根目录下的.flowconfig，不能留空或填错名（比如写成flowconfig少个点） - 如果项目有多个子包（如 monorepo），每个包需有自己的
.flowconfig，且 WebStorm 当前打开的是该包根目录
确保文件被 Flow 实际扫描（@flow 注释 + include 规则）
即使配置全对，WebStorm 也不会对任意 JS 文件做类型检查 —— 它严格遵循 Flow 自身的判定逻辑：文件开头有 // @flow，且该文件路径匹配 .flowconfig 中的 [include] 规则。
- 缺
// @flow注释的文件，WebStorm 显示灰色高亮，但零错误提示 -
.flowconfig默认只有[ignore]段，没有[include]段时，Flow 只检查显式声明了// @flow的文件，且这些文件必须在项目根目录或子目录下（不跨盘符） - 常见陷阱：
[include] .*/src/**/*写成[include] ./src/**/*—— 开头少个.会导致正则不匹配，src 下所有文件都被忽略 - Vue 项目中
.vue单文件组件默认不支持 Flow，需配合vue-flow插件或转用<script lang="ts"></script>
调试 Flow 报错不显示或延迟高的问题
Flow server 启动失败或卡住时，WebStorm 的类型提示会静默失效，看起来像“配置没生效”，其实只是后台进程挂了。
- 先在终端运行
flow status：若返回Could not start Flow server，说明 server 启动失败，常见原因是.flowconfig语法错误（如多了一个逗号）或 Node 版本不兼容（Flow v0.200+ 要求 Node ≥18.17） - WebStorm 底部状态栏左下角会显示
Flow: Ready或Flow: Starting…，长时间卡在后者就该去 Terminal 查flow status - 频繁修改
.flowconfig后，WebStorm 不会自动重启 Flow server，需手动执行flow stop && flow start，或重启 WebStorm - 大型项目首次启动 Flow server 可能长达 30 秒以上，期间无任何提示，别误判为失败
最易被忽略的一点：WebStorm 的 Flow 集成完全复用官方 Flow CLI 行为，它不提供额外的类型推断或绕过规则的能力。任何你在终端跑 flow check 看不到的错误，在编辑器里也看不到 —— 别试图在 IDE 设置里“强制开启某类检查”，那没用。
