VSCode中运行Flyway迁移的关键是通过tasks.json调用本地Flyway CLI，而非依赖插件；需确保flyway命令可执行、连接配置正确（如flyway.conf路径或显式参数）、脚本命名严格符合Vx__desc.sql规范，且数据库URL指向真实目标库。
VSCode里直接跑Flyway迁移，关键不是装插件而是调CLI
VSCode本身不内置Flyway支持，所谓“集成”本质是调用本地或项目内安装的flyway命令行工具。你不需要找什么“Flyway for VSCode”插件——那些基本已废弃或功能残缺。真正稳定、可控的方式是通过tasks.json定义任务，让VSCode终端执行flyway migrate这类命令。
常见错误现象：点了“运行任务”却报command 'flyway' not found，或日志里出现Unable to connect to database但连接参数明明写对了——问题往往出在环境变量没继承、JDBC驱动缺失，或flyway.conf路径不对。
- 确保已在系统PATH中可用：
flyway -v能在任意终端输出版本号 - 若用项目级Flyway CLI（如通过
./mvnw flyway:flyway），任务里要明确指定Maven wrapper路径 -
flyway.conf必须放在项目根目录或~/.flyway/下；VSCode任务默认不读取src/main/resources/application.yml里的spring.flyway.*配置 - Java项目若依赖
flyway-mysql等驱动包，CLI模式下需手动把对应JAR加到flyway.driver或CLASSPATH中
tasks.json怎么写才能正确触发Flyway migrate
VSCode的任务系统是核心载体，.vscode/tasks.json里每条任务对应一个可复用的迁移动作。重点不是语法多漂亮，而是参数是否匹配当前环境的真实路径和权限。
使用场景：开发时快速应用新SQL脚本、验证回滚逻辑、检查迁移状态，避免切出编辑器开新终端。
- 基础
migrate任务示例（假设flyway.conf在项目根目录）：{ "version": "2.0.0", "tasks": [ { "label": "flyway:migrate", "type": "shell", "command": "flyway migrate", "group": "build", "presentation": { "echo": true, "reveal": "always", "focus": false, "panel": "shared", "showReuseMessage": true, "clear": true } } ] } - 若数据库连接信息不在
flyway.conf中，必须显式传参："command": "flyway -url=jdbc:mysql://localhost:3306/test -user=root -password=123456 migrate" - 想区分环境？别硬编码URL，改用
-configFiles=conf/flyway-dev.conf指向不同配置文件 - 执行失败时看控制台第一行错误：如果是
No migrations found，大概率是flyway.locations指向的目录不存在或没SQL文件；如果是Checksum mismatch，说明你改了已执行过的V脚本——这属于严重误操作
V1__init.sql命名错一个字符，VSCode里就永远跑不通
Flyway对脚本名的解析极其严格，VSCode里点运行任务看似简单，但背后校验失败会直接中断，且错误提示常藏在几十行日志底部。命名不是“差不多就行”，而是规则驱动的字符串解析过程。
参数差异直接影响执行顺序和是否被识别：V前缀、双下划线分隔、SQL后缀，三者缺一不可；版本号里的_会被转成.再做数字比较，V1_10__实际排序在V1_2__之后——这不是bug，是设计。
- 合法命名：
V1__create_user.sql、V2_1__add_index.sql、R__load_dict_data.sql - 非法命名：
v1__create_user.sql（小写v）、V1-create-user.sql（用短横）、V1__create_user.SQL（大写后缀）、V1.1__desc.sql（点号在前缀后不允许） - 不要在已有V脚本上改内容：一旦
V1__init.sql被应用过，再修改它会导致Validate error: Migration checksum mismatch，只能删表重来或手动更新flyway_schema_history里的checksum字段（不推荐） - 新增脚本时，版本号必须严格递增：从
V1跳到V3会报outOfOrder = false错误（默认启用），除非显式设flyway.outOfOrder=true
为什么VSCode里能看到迁移成功日志，但数据库里没建表
这是最让人抓狂的场景：控制台刷出Successfully applied 1 migration，刷新数据库却找不到新表。根本原因往往是Flyway连到了“假库”——不是你以为的那个。
性能与兼容性影响：Flyway CLI默认用H2内存库做测试，而Spring Boot项目里的application.yml配置对CLI完全无效。VSCode任务里没指定URL，就可能连上本地H2或空MySQL实例。
- 第一步确认连接目标：
flyway info任务会列出当前配置的flyway.url，复制出来手动用mysql -h -P -u -p连一下 - 第二步检查schema是否匹配：MySQL里
flyway.url=jdbc:mysql://localhost:3306/mydb，但你登录的是mydb_test库，那迁移就发生在另一个库里 - 第三步看
flyway_schema_history表在哪：它默认建在URL指定的库下，如果该库为空，Flyway会自动创建此表；但如果库名拼错，它可能建在information_schema或其他系统库中（极少见但发生过） - 别依赖“自动创建表”：有些旧版Flyway或自定义
flyway.table值时，不会自动初始化flyway_schema_history，得先手动执行flyway repair或flyway baseline
真正的难点从来不在VSCode界面操作，而在于CLI环境、脚本命名、数据库连接三者的精确咬合。任何一个环节的隐式假设（比如“它应该读我的application.yml”“大小写无所谓”“改个注释没关系”）都会让迁移静默失败。动手前，先在终端里单独跑通flyway info和flyway validate，比反复点VSCode任务更省时间。
