这个标题看着像语法科普，其实做 ABAP 时间长了你会发现，它直接关系到你维护老程序时的心态。方法参数这几个关键字，IMPORTING、EXPORTING、CHANGING、RETURNING，再加上 VALUE 和 REFERENCE 这对隐藏语义，很多同事写了两三年 ABAP OO 还是凭感觉在填签名，接口调通了就再也不看。真正出事的时候，往往都是那种“方法内部改了入参，调用方变量被悄悄污染”“大表整体 VALUE 传参，性能跑批从几分钟拖到半个多小时”之类的隐蔽问题。
这篇不是照着 ABAP 帮助文档翻译一遍，而是按我在多个 S/4HANA 项目里实际沉淀下来的理解，把每个参数关键字的调用约定、内存语义、适用边界拆开讲，最后附带三个真实事故复盘和一套我用来设计签名的判断清单。文章尽量直接给结论，也尽量把为什么是这样讲透。无论你是刚接触 ABAP OO 的开发者，还是已经在项目里写了大量自定义类的老手，里面都有值得对照检查的地方。
1. IMPORTING 的默认传递方式，藏着 ABAP 的“性能执念”
1.1 不写 VALUE 的 IMPORTING，相当于把变量地址借给了方法
先把最重要的底层事实摆在最前面：一个 IMPORTING 参数，如果没有显式加 VALUE，它默认是按引用传递。用大白话说就是，方法内部拿到的并不是调用方变量的复印件，而是指向同一块内存地址的“引用”。方法里读这个参数，读到的是调用方当前的值；方法里写这个参数，写的就是调用方变量本身。
下面这段代码完全能通过编译：
METHOD increment_input. IMPORTING iv_counter TYPE i. iv_counter = iv_counter + 1. ENDMETHOD.调用端如果传进来一个变量：
lv_count = 100. mo_service->increment_input( IMPORTING iv_counter = lv_count ). * lv_count 已经变成 101你可能觉得这不合理——IMPORTING 不是“输入”吗？怎么还能改？但 ABAP 语法层面并不禁止你修改 IMPORTING 参数。不写 VALUE 时，它就是一个地址别的通道，编译器完全不拦你。真正把“输入”当“常量”来约束的，是工程师自己的编码纪律，不是语言规则。
我在代码评审里不止一次见过这种写法被带进生产代码，尤其是从老式 FORM/PERFORM 迁移过来的同事，顺手把以前“传进来当临时变量用”的习惯带到方法里。当时不出问题，是因为调用方那个变量后面的逻辑恰好不再依赖它了。一旦哪天有人把这段方法接到一个更长的流程里，变量被污染的问题就会突然冒出来，排查方向往往还会先指向业务逻辑错误，而不是方法签名。
1.2 默认 REFERENCE 不是偷懒，是 R/3 时期的性能选择
那 ABAP 为什么不默认传值，把这种误伤可能性消灭在语法层？答案跟 ABAP 的历史深度绑定。R/3 时代的内存和 CPU 都是稀缺资源，一个内部表动辄几万行，方法调用时如果传值就是整表复制，再跑去排序、过滤、循环，服务器很快就扛不住了。按引用传参数，复制成本为零，调用栈上的开销可以忽略。所以 ABAP 把 REFERENCE 定为默认，把 VALUE 留成一个需要显式选择的防御选项。
这个设计本身没有对错，但它确实把“安全”交给了开发者。到今天 S/4HANA 环境下内存资源宽裕了很多，很多新代码里你仍然会看到各种方法签名不带 VALUE。延续历史习惯是一方面，但更多时候是大家根本没有意识到这是引用传递，误以为“IMPORTING 天然是只读的”。
1.3 该显式写 VALUE 的地方，别省
基于上面这些，我对 IMPORTING 的推荐做法其实很朴素：
- 基础类型变量，比如 I、C、STRING、日期时间，显式写 VALUE。拷贝开销几乎为零，还能防止方法内部意外写回。
- 中小型结构，尤其是方法里只是读取字段做判断的，也写 VALUE。成本和安全性对比非常划算。
- 大内部表，先别急着写 VALUE。整表复制可能吃掉几十毫秒甚至更多，后面要结合数据规模来定复制策略。
还有一个非常容易被忽略的细节：如果一个 IMPORTING 参数声明了 VALUE，方法内部再怎么修改这个参数，调用方都无感知。这给单元测试带来了很大的便利，你可以独立测试方法逻辑，而不必担心测试数据被方法改写。推荐把“IMPORTING 一律按只读参数对待”这个约定写进团队开发规范，比依赖每个人自觉要稳得多。
2. RETURNING 与 EXPORTING：一条返回路线的两种走法
2.1 RETURNING 是函数式调用的“单值通道”
RETURNING 参数在 ABAP 里的定位非常纯粹：恰好返回一个值，且编译器强制要求以值传递方式返回。它让方法可以像函数一样直接嵌进表达式中使用，这是 RETURNING 和 EXPORTING 最直观的差异。
METHOD calculate_discount. IMPORTING iv_amount TYPE i RETURNING VALUE(rv_discount) TYPE i. rv_discount = iv_amount * 10 / 100. ENDMETHOD. lv_final = lv_price - mo_pricing->calculate_discount( iv_amount = lv_price ).调用方拿到 RETURNING 值的时候，不需要先准备一个接收变量，直接把方法调用写进赋值语句的右边就行。这个特性让代码非常紧凑，也让调用链变得很像函数式编程。
RETURNING 参数同时有两条硬性规则，很多人不一定清楚：
- 只能声明一个，不能有多个 RETURNING。
- 不能声明为 OPTIONAL，也就是说方法要么返回这个值，要么抛异常，不存在“这次不返回”的可能。
这两条规则决定了 RETURNING 特别适合纯计算、单表查询、状态映射这类“有确定性产出”的方法。如果一个方法的产出天然是零个或多个，RETURNING 语义上就不合适了。
RETURNING 返回内部表的情况也很常见。方法内部构建一张新表返回，调用方直接接住，这种写法比先声明接收表再传引用清晰很多：
lt_filtered = mo_data->get_filtered_items( iv_status = 'ACTIVE' ).这里要提一个我见过多次的误解：有人以为 RETURNING 表是引用，性能一定更好。实际上 RETURNING 是按值语义，调用方接收时同样存在复制成本。别因为写法漂亮就忽略数据规模，大表返回时依然要思考复制代价。
2.2 多个返回值才知道 EXPORTING 的重要性
当方法需要回传多个信息，比如一个员工的主数据、部门名称、权限清单，RETURNING 就无能为力了，因为只能传一个值。这时候标准做法是多声明几个 EXPORTING 参数。
METHOD get_employee_full. IMPORTING iv_employee_id TYPE i EXPORTING ev_name TYPE string ev_dept TYPE string et_roles TYPE string_table. ENDMETHOD.调用端要对应接收：
mo_employee->get_employee_full( EXPORTING iv_employee_id = lv_id IMPORTING ev_name = lv_name ev_dept = lv_dept et_roles = lt_roles ).我的经验里，EXPORTING 参数的个数最好不要超过三个。一旦超过三个，方法内部的赋值逻辑会开始变得难以追踪，调用端也是一长串 IMPORTING 块。这时候更推荐把结果封装成一个结构或一个专门的结果类，用 RETURNING 整体返回。比如上面这个例子，改成 RETURNING 一个ys_employee_full结构，调用端代码会短很多，结构本身就成了数据的契约，后面加字段也不影响已有调用点。
2.3 EXPORTING 参数的“残留值”坑
EXPORTING 参数和 RETURNING 参数有一个非常容易踩的实际差异：方法如果执行到最后都没有给某个 EXPORTING 参数赋值，调用方传进来的接收变量会保持原值，不会被清成初始值。RETURNING 不会这样，它无论如何都会给调用表达式一个结果。
这个差异在循环批量处理时特别危险。举个真实场景：一个程序循环处理多张单据，每次调用某个导出方法，方法内部只在特定分支条件下给ev_status赋值。第一张单据条件满足，lv_status被设成“已审批”；第二张单据条件不满足，方法内部没给ev_status重新赋值，结果lv_status还是上一张的“已审批”。到月底汇总时，第二张单据被误统计成已审批，整个报表口径就错了。
修复方式很简单，方法开头把每个 EXPORTING 参数先赋一个明确的默认值：
ev_status = 'UNKNOWN'.这个习惯应该写进方法实现的第一行，而不是依赖调用方每次先初始化接收变量。调用方没有义务为你补偿方法的未赋值路径。
3. CHANGING 的真正语义：改原来的值，还是带回一个新值
3.1 先看清 CHANGING 和 IMPORTING + RETURNING 的差别
CHANGING 参数表面上也是“传进去再带出来”，容易和 IMPORTING + RETURNING 混淆。但底层语义完全不同。CHANGING 参数默认也是按引用传递的，意思非常直白：方法读取这个变量的当前值，就地修改它，修改结果直接写回调用方的同一块内存。
METHOD increase_quota. CHANGING cv_quota TYPE i. cv_quota = cv_quota + 100. ENDMETHOD.调用方不需要接收新值，因为原有的变量已经变了：
lv_quota = 50. mo_quota->increase_quota( CHANGING cv_quota = lv_quota ). * lv_quota 现在等于 150同样的效果用 IMPORTING + RETURNING 也能实现：
lv_quota = mo_quota->calc_increased_quota( iv_quota = lv_quota ).两者的内存行为不一样。RETURNING 模式下，方法内部算出新值后重新赋值给调用方变量，这个变量在调用前后经历的是“重新绑定一个新值”的过程。而 CHANGING 模式下，从头到尾就是同一块内存，方法在原有内容上做修改，所有持有这个变量引用的地方都会看到新状态。
什么情况下这个差别会真正影响业务？当你已经把变量引用传给了某个对象、事件或者锁表时，原地修改和重新赋值带来的是两类效果。比如一个统计对象内部累计了 N 个引用，你原地改了其中一个源变量，统计对象里的值也跟着变；你重新给外部变量赋值，统计对象里保留的依然是旧值的快照。这种细微差别，排查起来非常费劲，所以最好在写签名的时候就想清楚要哪一种。
3.2 哪些场景适合 CHANGING
基于“原地修改”这个核心语义，我通常只在下面几种场景里用 CHANGING：
- 计数器、累计器。比如统计循环里对总数自增，这是 CHANGING 最经典的适用场景。
- 需要更新传入对象的多个内部状态，且调用方依赖同一个对象引用的场景。
- 状态机流转，方法内部根据当前状态推进到下一个状态，调用方继续持有同一个状态变量。
这些场景的共性就是：调用方明确希望“这个变量在我手上被改掉”。这时候用 CHANGING，读代码的人一看签名就能理解方法会改动外部状态，这是它的价值所在。
3.3 被误用成“万能输出”的 CHANGING
实际代码里最常见的误用，是把一张“输入表”和一张“输出表”同时塞进 CHANGING，理由很简单——“反正都要传，CHANGING 又能进又能出，最方便”。
这种写法的隐患在于语义完全错位。如果方法内部是从零构建一张新表，它并没有“修改传入的原始表”，它只是借用了 CHANGING 位置的通道。读代码的人看到 CHANGING 表，第一反应会是“方法会就地给这张表增删改行”，一旦方法实际行为不是这样，误解就产生了。
CHANGING 应该只留给真正需要原地修改的变量。方法国内构建的新表，该用 EXPORTING 就用 EXPORTING，该用 RETURNING 就用 RETURNING。把参数的语义表达清楚，比省一个关键字重要得多。
4. VALUE 和 REFERENCE 的复制成本：这笔内存账得算清楚
4.1 传值开销发生在哪两个时间点
VALUE 传参，实际上是在两个时间点产生复制成本：方法进入时复制一次入参，方法退出时复制一次出参。对基本类型来说，这几个字节的栈拷贝可以忽略；但参数一旦是字符串、结构或内部表，复制开销就跟数据大小严格成正比。
以前面说的内表为例，一个标准内表如果按行存储，假设 10 万行、每行 200 字节，经验上VALUE一次进入调用就要拷出大约 20MB 的量级，方法内部再做排序、过滤，出参的时候可能又来一次。这种成本叠加起来，跑批程序变慢就一点都不意外了。
REFERENCE 传参几乎避免了所有复制，只传一个指向真实数据的位置信息，运行代价极低。但代价换成了风险：方法内所有改动都会直接体现在调用方原始数据上。所以在决定用 REFERENCE 之前，必须想清楚这一步。
这里要特别强调一下：所谓“引用”，在 ABAP 上下文里就是共享内存访问。不要拿面向过程的FORM ... CHANGING ...旧习惯去套，逻辑是一脉相承的，但方法的封装边界比 FORM 往往更复杂，也更需要明确数据所有权。
4.2 深拷贝和浅拷贝：结构、内部表和对象引用的不同命运
VALUE 传参的复制深度，很多人没有细究过。ABAP 的传值复制对结构是深拷贝——结构里的每个字段都会复制一份；对内部表也是深拷贝——表里的每一行都会复制，包括行里的结构。这跟其他语言里“浅拷贝共享内层结构”的行为不一样。也就是说，给方法传一个 VALUE 内表，方法内修改任意一行，调用方的原表完全不受影响，安全性很高，代价就是完整复制成本。
但有一种数据类型要小心：对象引用，也就是类的实例引用。它的复制行为是，值传递只是复制引用本身，两个引用指向的还是同一个对象实例。所以如果你给方法传一个 VALUE 的对象引用参数，方法内部通过这个引用去调方法、改属性，照样会改动调用方持有的同一个对象。对象内部状态不会被自动深拷贝。
这个问题在项目里通常以“我以为传值就安全了，结果对象属性在外面还是变了”的形式出现。正确理解是：VALUE 只保护“引用变量本身”不被重新指向，不保护“被引用对象”的内部状态。
4.3 大表现在怎么处理：引用传进来，第一行拷贝防御
大表参数最合理的一套做法，我总结成下面这个模式。入参用引用传，省掉一次大复制；方法第一行显式创建本地副本，后续改动的只是副本，外部数据安全。
METHOD process_large_table. IMPORTING iv_table TYPE STANDARD TABLE OF line_type. DATA(lt_local) = iv_table. * 后面所有排序、过滤、修改都基于 lt_local ENDMETHOD.这种做法的开销仍然是复制一次全表，但主动权回到了方法内部，而且可读性比在签名上写 VALUE 更明确，读代码的人一眼能看到“这里在做防御性拷贝”。特别适合那种数据量大、你又不能保证方法内部不会误改外部状态的场景。
如果方法确实只是读取大表，不打算做任何修改，也可以直接引用处理，但强烈建议在方法注释里写明“该参数按引用传入，方法内只读”。否则后来维护的人看到一个大内表引用参数，大概率会先怀疑你自己改坏了什么。
5. 项目中真实踩过的三个参数事故
5.1 签名定太窄，需求一变就得全链路改造
之前做过一个采购订单审批增强，最开始设计方法时图简单，签名写成：
METHODS check_approval IMPORTING iv_amount TYPE i RETURNING VALUE(rv_ok) TYPE abap_bool.业务跑了一个季度都很稳。后来业务方要求加一层成本中心维度的审批，还要区分不同审批链。结果这个方法从“返回一个布尔值”直接被迫改成“导出审批结果对象”，下游十几个调用点全部跟着改，本来一个下午能完成的需求，硬生生变成全链路回归。
教训就是：方法签名一旦发布，就是跟调用方的长期契约。在业务需求快速变化的环境里，一开始就把入参设计成结构，至少预留扩展字段的空间，比一开始图省事定成单一基础类型要明智得多。签名要有“未来感”，哪怕现在只有一个字段，也要想想明天会不会冒出来第二个。
5.2 大表全 VALUE 传参，几千条记录就把跑批拖垮了
有个库存对账接口，每天处理几万条记录，方法里做校验并返回结果表。早期代码为了安全，所有参数都写 VALUE。单测数据量小看不出来，一上生产，单次调用的时间从几十毫秒涨到几百毫秒，整体跑批从预期的一小时慢到两个多小时。
定位后发现瓶颈就在参数复制上：输入表 VALUE 一次，输出表 RETURNING 一次，内表行结构还特别宽，光复制就占掉接口 60% 以上的时间。后来把输入表改成按引用传入，方法内部视情况决定是否复制；输出表保留 RETURNING，但输出行只保留真正需要返回的字段，而不是整行结构。性能恢复到了毫秒级。
这件事让我真正认可了一个原则：参数设计必须结合数据规模评估。语法上正确的代码，不等于生产上可运行的代码。
5.3 方法内部改写 IMPORTING 引用，把调用方状态弄脏
有个同事写了个校验方法，传入一个状态码，本意是读取状态做判断。但方法内部直接把这个状态码当成中间变量反复覆盖，最后返回给调用方的时候，状态码已经不是最初传入的值了。单元测试里每个用例都是独立数据，全绿；集成环境里两个调用点数据有前后依赖，立刻就乱了。
问题根源还是没写 VALUE，以及把 IMPORTING 当临时变量用的习惯。后来团队评审把这类写法直接列为红线：IMPORTING 参数一律视为常量，方法内部任何需要改写的东西，必须自己新建本地变量。编译器不抓这件事，代码评审就必须抓。
6. 设计签名前的五个是非判断
做技术方案的时候，我不太喜欢列一堆“最佳实践”，因为每个项目的代码风格和数据规模都不一样。但方法签名的选择确实存在一些普适的判断顺序，我现在每次写方法前都会在脑子里过一遍，这里整理出来。
6.1 返回值是一个还是多个
只有一个返回产出，优先 RETURNING。两个以上，先看能不能封装成结构用 RETURNING 返回；封装不了，再用 EXPORTING。这一条能解决大部分签名纠结。
6.2 是不是要保留同一变量的引用
如果调用方希望方法执行完后，原来那个变量还是原来那块内存、只是内容被更新，那就用 CHANGING。如果调用方不关心老引用，只关心拿到新值，用 IMPORTING + RETURNING。
6.3 数据规模是否值得为防御性拷贝掏钱
几百行的表，VALUE 随便写。几十万行的表，先想清楚方法是否真的需要修改数据，以及调用方能不能接受原数据被改。大表参数优先引用传入，方法内第一行做防御性本地复制，这样安全和性能都可控。
6.4 这个方法未来会不会变
新需求催生新字段是常态。一个方法如果大概率会扩展，签名上少用单体基础类型，多用结构或对象。结构扩字段是低成本的，把签名从单一参数改成多 EXPORTING 参数则是高成本的。
6.5 调用方期望什么风格的代码
纯计算逻辑用 RETURNING 函数式风格，可读性最好；有状态更新的逻辑用 CHANGING，意图最清楚；多结果查询用 EXPORTING，匹配 ABAP 的经典调用习惯。签名风格本身也是一种沟通语言，保持跟团队代码库主风格一致，比追求某个“绝对正确”重要得多。
6.6 我愿意在签名旁边留的第一行注释
最后分享一个实操习惯。我现在每写一个方法，都会在方法属性注释里写一句话，说明这个方法的签名为什么这样设计，重点标注哪些参数是按引用传入、哪些是允许被修改的。等半年后自己或同事回来看这段代码，不需要重新推断“这个方法会不会动我的变量”，直接读注释就够了。这个方法本身不一定有那么多弯弯绕绕，但注释能省掉一半的猜测时间。
ABAP OO 的方法参数，本质上就是你和调用方之间的沟通协议。一个签名如果可能有两种解读方式，它迟早会变成凌晨的排查电话。与其等到踩坑，不如在设计签名的时候多问自己几个为什么。
