MapForce中无真正全局变量，可用项目级常量、只读Input Parameters和User-Defined Functions替代；误用外部存储模拟将导致并发错误与导出失败。
全局变量在 MapForce 中并不存在——但有等效替代方案
MapForce 本身不提供传统编程语言意义上的「全局变量」（如 global varName），它没有跨映射、跨组件作用域的可写变量声明机制。你看到的所谓“全局变量”，实际是三种受限但实用的替代设计：项目级常量、输入参数（Input Parameters）、以及通过 User-Defined Functions 封装的复用逻辑。误以为能像 C# 或 Python 那样定义和修改全局状态，是新手最常见的认知偏差，直接导致映射调试失败或输出不可控。
用 Input Parameters 模拟“只读全局变量”
这是最常用、最安全的方案。你可以在项目根节点右键 → Add Input Parameter，定义一个带默认值的参数（如 baseCurrency = "USD"），然后在任意映射组件中拖入该参数，作为常量参与计算或条件判断。
- ✅ 优点：可在运行时通过命令行（
mapforce.exe /param:baseCurrency=EUR ...）或 API 动态覆盖，适合多环境部署 - ⚠️ 注意：不能在映射执行过程中被修改；若尝试用
Set Variable类函数写入它，会报错"Parameter is read-only" - ? 场景举例：统一控制日期格式化模板、API 基础 URL、税率系数——所有地方都引用同一个
taxRate参数，改一处全生效
用 User-Defined Function 封装“带逻辑的全局行为”
当你需要的是「可复用+带计算逻辑」而非纯值，就该建自定义函数。例如创建一个叫 formatInvoiceID 的函数，接收 rawID 和 prefix，返回大写加时间戳的字符串。它在项目内任何映射里都能被调用，效果接近“全局方法”。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- ✅ 优点：支持参数、分支、循环（通过内置函数组合）、可调试、可导出为独立代码模块
- ⚠️ 坑点：函数内部无法访问当前映射的上下文数据（如当前行号、源记录对象），只能靠显式传参；不能读取其他映射里的中间结果
- ? 示例：想让所有订单号都加上
"ORD-" + YYYYMMDD + "-" + sequence，就把这整段逻辑封装进函数，而不是在每个目标字段里重复拖拽concat、date、counter函数
为什么别碰“伪全局”技巧：比如用数据库临时表或文件存状态
有人试图用 SQL INSERT INTO #temp 或写入本地 config.txt 来模拟跨映射通信——这不仅违反 MapForce 的无状态设计原则，还会引发严重问题：
- ❌ 并行执行时数据竞争（尤其服务器版启用多核优化后）
- ❌ 映射失败时临时状态残留，下次运行污染结果
- ❌ 导出为 Java/C# 代码后，这些外部 I/O 不会被自动翻译，导致编译失败或静默跳过
- ? 正确思路：把需要“传递”的状态，明确设计成上层流程的输出 → 下层映射的
Input Parameter，由调度器（如 Windows Task Scheduler、Jenkins 或自研服务）串联
真正容易被忽略的是：MapForce 的“全局性”必须从项目结构层面设计，而不是靠某个按钮或隐藏配置。如果你发现十几个映射都在硬编码同一串路径或 ID，那不是缺全局变量，而是该重构为参数化项目了。
