实现旧项目函数声明自动化升级的关键是构建可验证、可回退、分阶段的配置化重构流程，依赖工具链协同而非万能脚本；需明确定义不规范范围，按语言选用Rector、tsc+ESLint、/permissive-、mvn编译警告等成熟工具，封装带Git分支、测试验证、dry-run报告和白名单的安全执行流程，并通过签名对比、diff检查、smoke test及保留deprecated注释确保无损。

要实现旧项目中不规范函数声明的平滑、无损自动化升级，关键不是写一个“万能脚本”，而是构建一套可验证、可回退、分阶段执行的配置化重构流程。它依赖工具链协同，而非单个脚本硬编码逻辑。

明确识别目标：哪些“不规范”需升级

先定义清楚范围，避免误改。常见需升级的函数声明问题包括：

• PHP 中已废弃的 create_function()、each()、split() 等动态或过时写法
• JavaScript/TypeScript 中缺少类型标注、参数未声明、返回值隐式 any 的函数
• C++ 中非标准写法（如省略 typename、依赖 MSVC 特有扩展）
• Java 中使用已弃用 API（如 Thread.stop()）或未加泛型约束的原始集合操作

不同语言对应不同检测规则，不能混用同一套配置。

选对核心工具并配置规则集

跳过自研脚本，直接复用成熟工具的标准化能力：

• PHP：用 Rector + PHPCompatibility。在 rector.php 中按版本阶梯配置，例如先启用 SetList::PHP_74，验证通过后再加 PHP_80
• TypeScript：启用 tsc --noEmit --watch 配合 allowJs:true 和 checkJs:true，再用 ESLint 的 @typescript-eslint/no-explicit-any、no-undef 等规则定位问题函数
• C++：开启 Visual Studio 的 /permissive- 编译选项 + 启用 C++20 标准，IDE 自动标出所有非标函数签名（如未加 override 的虚函数重写）
• Java：用 mvn compile -Dmaven.compiler.source=25 -Dmaven.compiler.target=25 触发编译器警告，配合 java -Xlint:deprecation 输出具体位置

封装安全执行流程（推荐 shell / npm script）

把工具调用包装成带保护机制的命令，而不是裸跑重构：

• 每次运行前自动创建 Git 分支（如 refactor/function-signatures-202606）并暂存当前状态
• 执行重构命令后，自动运行单元测试（npm test 或 phpunit），失败则立即 git reset --hard
• 生成变更摘要报告（如 Rector 的 --dry-run 模式输出修改文件列表和行号）
• 支持白名单过滤：用 --path=src/utils/ 限定作用域，避免误触核心业务逻辑

示例（PHP 项目）：

#!/bin/bash
git checkout -b refactor/fn-signatures-$(date +%Y%m%d)
vendor/bin/rector process src/ --set php74 --dry-run --ansi
read -p "确认执行？(y/N) " -n 1 -r
if [[ $REPLY =~ ^[Yy]$ ]]; then
  vendor/bin/rector process src/ --set php74
  composer test && echo "✅ 重构通过" || (git reset --hard; echo "❌ 测试失败，已回退")
else
  git checkout -
fi

验证与收口：确保“无损”的最后防线

自动化只是第一步，真正的“无损”靠验证闭环：

• 对比重构前后函数签名是否影响调用方（尤其检查 TypeScript 的 noImplicitAny 是否引发新报错）
• 用 diff 工具比对关键接口文件，确认无新增/删减逻辑语句，仅改动声明部分
• 对升级后的函数做最小 smoke test：调用一次，检查返回值类型、结构、副作用是否一致
• 保留旧版函数声明注释（如 // @deprecated use greetUser(name: string): string instead），供后续人工审查

不复杂但容易忽略