企业官网建设流程全解析

1. 为什么ALV多屏幕布局不是“加个屏幕号”就能搞定的事

在SAP ABAP开发中，REUSE_ALV_GRID_DISPLAY_LVC这个函数模块几乎是每个中级以上开发者每天都要打交道的“老朋友”。但凡做过报表、列表展示、数据核对类功能，几乎都绕不开它。可真正用得深、用得稳、用得明白的人，其实不多。我见过太多项目里，开发同事把ALV当成“万能表格控件”，简单调用一次就完事——结果上线后用户一抱怨：“怎么点个按钮就跳回主屏幕？”“为什么我刚在子屏幕改完数据，回到主表就没了？”“状态栏按钮文字怎么全是英文？客户说看不懂！”——这时候才翻出代码一看：handle参数全设成空，screen字段硬编码写死，GUI_STATUS直接套用标准模板……问题不是出在ALV本身，而是出在对handle机制的理解断层上。

所谓“多屏幕独立布局”，绝不是指“我在SE38里写了两个程序，一个叫ZALV_MAIN，一个叫ZALV_DETAIL”这么简单。它的核心在于：同一份ALV实例，在不同屏幕上下文中，能维持各自的状态、事件响应逻辑、工具栏行为和数据视图边界。比如你在采购订单明细页（屏幕100）点开一个物料主数据弹窗（屏幕200），这个弹窗里的ALV必须能独立响应F4帮助、双击跳转、自定义按钮点击，且不干扰主屏幕ALV的滚动位置、筛选条件、列宽记忆——而这一切，全部依赖handle参数的精准构造与生命周期管理。

关键词里反复出现的“handle”，正是这个机制的命门。它不是一个可有可无的形参，而是ALV运行时的“身份ID+控制中枢+状态容器”三位一体。官方文档里只说“传递一个类型为LVC_S_LAYO的结构体”，但没告诉你：这个结构体里的每一个字段，都在决定ALV在当前屏幕上的“人格”。比如i_structure_name决定了字段目录来源，i_callback_program锁定了事件回调归属，is_layout-cwidth_opt开启与否直接影响用户拖拽列宽后的持久化效果——这些细节，不实测、不调试、不读源码，光看Help文档根本摸不到边。

更关键的是，网络热词里频繁出现的sap md07（MRP清单）、sap miro拆分增强、abap mm01 mm02 mm03物料主数据新屏幕增强，背后全是ALV多屏协同的真实战场。MD07里点击某行物料跳转到库存明细，那个弹窗ALV必须能按批次、按仓位分组显示；MIRO拆分增强后，主凭证ALV和拆分明细ALV要共享部分筛选条件但又各自维护排序逻辑；MM01新增业务字段后，增强的ALV子屏幕必须能独立触发校验、保存、回滚——所有这些，都卡在handle参数是否被正确初始化、是否被正确复用、是否被正确释放上。

所以，这篇内容不讲“怎么调用函数”，而是带你一层层剥开handle背后的运行契约：它如何绑定屏幕、如何隔离事件、如何承载状态、如何避免内存泄漏。这不是ABAP语法课，而是一次面向生产环境的ALV治理实践。

2. handle参数的本质：ALV运行时的“身份证+控制台+状态箱”

很多人把handle当成一个“传进去就行”的句柄变量，声明一个DATA: g_handle TYPE REF TO OBJECT，然后CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY_LVC' EXPORTING i_callback_program = sy-repid ... i_grid_title = '物料清单' ... CHANGING it_outtab = gt_data et_fieldcat = gt_fcat. 这样调用确实能跑起来，但只要涉及多屏幕，立刻崩盘。原因很简单：你没给ALV发一张“身份证”，也没给它配一个“控制台”，更没给它准备一个“状态箱”。

我们先看handle参数在函数接口中的真实定位。REUSE_ALV_GRID_DISPLAY_LVC的CHANGING参数里，有两个关键handle：

• i_grid_title：只是标题字符串，无关紧要；
• i_structure_name：指定内表结构名，影响字段目录生成；
• 真正起决定性作用的是i_callback_program和is_layout中的i_callback_*系列字段，以及i_save、i_default等控制开关——它们共同构成了handle的逻辑内核。

但ABAP里没有名为“handle”的显式类型。所谓handle，其实是一组严格关联的参数组合，其有效性完全取决于它们之间的契约关系。这个契约包含三个不可分割的维度：

2.1 身份维度：谁在调用？在哪调用？为谁服务？

i_callback_program是handle的“户籍所在地”。它必须是当前调用ALV的程序名（sy-repid），不能是其他程序，也不能是空。为什么？因为ALV内部会用这个值去查找对应的TOP INCLUDE、FORM例程、GUI STATUS资源。如果你在ZMM_ALV_MAIN里调用ALV，却把i_callback_program设成ZSD_ALV_DETAIL，那么当用户点击工具栏按钮时，ALV会去ZSD_ALV_DETAIL里找USER_COMMANDFORM，结果当然是找不到，直接dump。

更隐蔽的问题是i_screen参数。很多开发者以为“只要在PBO里调用就行”，于是写：

CALL SCREEN 100. * 在PBO 100里： CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY_LVC' EXPORTING i_callback_program = sy-repid i_screen = 100 " ← 错！这里不能写死

这是致命错误。i_screen必须是当前动态屏幕号，即SY-DYNNR。因为ALV需要根据这个值去注册对应的PAI/PBO事件处理链。如果写死为100，而实际运行时用户从屏幕200跳转过来，ALV注册的事件处理器就挂载到了错误的屏幕上下文，导致双击、F4、按钮点击全部失效。

提示：永远用i_screen = sy-dynnr，而不是硬编码数字。这是保证handle身份合法的第一道防线。

2.2 控制维度：事件路由、状态同步、工具栏定制

is_layout结构体是handle的“控制台”。它里面藏着ALV行为的所有开关：

• is_layout-no_toolbar = 'X'：关闭整个工具栏（包括标准按钮和自定义按钮）；
• is_layout-colwidth_opt = 'X'：启用列宽自动优化（首次显示时按内容长度调整）；
• is_layout-cwidth_opt = 'X'：启用列宽记忆（用户拖拽后下次打开保持）；
• is_layout-sel_mode = 'A'：设置选择模式（A=全选，D=单选，C=复选框）；
• is_layout-zebra = 'X'：启用斑马纹；
• is_layout-grid_title = '自定义标题'：覆盖i_grid_title。

但最关键的，是is_layout里的回调字段：

• is_layout-i_callback_pf_status_set = 'SET_PFSTATUS'：指定状态栏设置FORM名；
• is_layout-i_callback_user_command = 'USER_COMMAND'：指定用户命令处理FORM名；
• is_layout-i_callback_top_of_page = 'TOP_OF_PAGE'：指定页眉打印FORM名。

这些回调FORM必须存在于i_callback_program指定的程序中，且必须是FORM类型（不能是METHOD）。ALV在渲染完成后，会主动调用SET_PFSTATUS来设置GUI STATUS，再在用户操作时调用USER_COMMAND来分发事件。这就是handle实现“控制”的核心路径——它不是被动接收参数，而是主动发起回调，把控制权交还给你的程序。

注意：SET_PFSTATUSFORM里必须调用SET PF-STATUS 'ZSTATUS'，且ZSTATUS必须在当前程序中通过SE41或SE80创建，并分配对应按钮。如果STATUS里定义了按钮但USER_COMMAND里没处理该功能码，点击就会报错。

2.3 状态维度：数据快照、布局记忆、事件上下文隔离

handle的第三个维度是“状态箱”，它体现在两个地方：it_outtab内表和et_fieldcat字段目录。

• it_outtab：不是简单的数据源，而是ALV的“当前工作副本”。ALV内部会对它做深拷贝、排序、过滤、分组等操作。如果你在多个屏幕间复用同一个内表变量（比如全局gt_data），那么屏幕100的排序状态会直接影响屏幕200的初始显示——这违背了“独立布局”的初衷。

• et_fieldcat：字段目录不是静态配置，而是ALV的“列元数据快照”。它记录了每列的标题、宽度、对齐、是否可编辑、是否隐藏等属性。如果你在屏幕100里动态修改了某列宽度（通过modify_column），这个修改不会自动同步到屏幕200，除非你显式重建fieldcat。

真正的状态隔离，靠的是为每个屏幕创建独立的handle上下文。这意味着：

1. 每个屏幕应有自己独立的数据内表（如gt_main_data, gt_detail_data）；
2. 每个屏幕应有自己独立的fieldcat（如gt_main_fcat, gt_detail_fcat）；
3. 每个屏幕的i_callback_program和i_screen必须准确指向自身；
4. 每个屏幕的is_layout结构体应独立声明并初始化，不能全局复用。

我曾在一个FICO凭证查询项目里踩过坑：主屏幕显示凭证头信息，双击行进入明细屏幕显示行项目。开发同事为了省事，把gt_detail_data和gt_main_data指向同一个内表，fieldcat也共用一个。结果用户在明细屏幕里把“金额”列拖得很宽，回到主屏幕发现“凭证号”列被挤没了——因为ALV的列宽记忆是基于fieldcat的col_pos和outputlen字段，而这两个字段在共用fieldcat时被互相覆盖了。

实操心得：在PBO中，永远用CLEAR清空fieldcat再重新BUILD；数据内表用REFRESH或MOVE-CORRESPONDING确保干净；is_layout结构体用CLEAR + MOVE-CORRESPONDING初始化，避免残留旧值。

3. 多屏幕实战：从主屏到弹窗的handle全生命周期管理

现在我们把理论落地。假设一个典型场景：采购订单主列表（屏幕100），点击某行物料，弹出库存明细弹窗（屏幕200）。要求两个ALV完全独立：主屏ALV保持滚动位置、筛选条件、列宽；弹窗ALV能独立排序、分组、导出，且关闭后不干扰主屏。

3.1 主屏幕（100）的ALV初始化：建立基础handle契约

首先，主屏幕的PBO逻辑：

*&---------------------------------------------------------------------* *& Module STATUS_0100 OUTPUT *&---------------------------------------------------------------------* MODULE status_0100 OUTPUT. SET PF-STATUS 'ZMM_PO_MAIN'. SET TITLEBAR 'ZMM_PO_MAIN'. " 1. 准备数据（模拟从数据库读取） PERFORM get_po_header_data CHANGING gt_header_data. " 2. 构建字段目录（必须为每个屏幕独立构建） PERFORM build_header_fieldcat CHANGING gt_header_fcat. " 3. 初始化layout结构体（关键！独立声明） CLEAR gs_layout. gs_layout-no_toolbar = space. " 启用工具栏 gs_layout-colwidth_opt = 'X'. " 列宽自动优化 gs_layout-cwidth_opt = 'X'. " 列宽记忆 gs_layout-sel_mode = 'A'. " 全选模式 gs_layout-zebra = 'X'. " 斑马纹 gs_layout-i_callback_pf_status_set = 'SET_PFSTATUS_MAIN'. gs_layout-i_callback_user_command = 'USER_COMMAND_MAIN'. gs_layout-i_callback_top_of_page = 'TOP_OF_PAGE_MAIN'. " 4. 调用ALV（注意i_screen = sy-dynnr！） CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY_LVC' EXPORTING i_callback_program = sy-repid i_screen = sy-dynnr i_grid_title = '采购订单主列表' i_structure_name = 'EKPO' " 结构名，影响字段目录 is_layout = gs_layout it_fieldcat = gt_header_fcat i_save = 'A' " 允许用户保存布局 i_default = 'X' " 使用默认布局 TABLES t_outtab = gt_header_data EXCEPTIONS program_error = 1 OTHERS = 2. IF sy-subrc <> 0. MESSAGE 'ALV显示失败' TYPE 'E'. ENDIF. ENDMODULE.

重点看gs_layout的初始化：所有字段都明确赋值，没有依赖全局变量；回调FORM名带_MAIN后缀，确保与主屏幕逻辑绑定；i_screen = sy-dynnr保证事件注册到当前屏幕。

3.2 主屏幕双击事件：触发弹窗并传递上下文

PAI中处理双击：

*&---------------------------------------------------------------------* *& Module USER_COMMAND_0100 INPUT *&---------------------------------------------------------------------* MODULE user_command_0100 INPUT. CASE ok_code. WHEN 'PO_DETAIL'. " 双击行时，获取当前选中行数据 READ TABLE gt_header_data INTO gs_selected_row INDEX gv_current_row. IF sy-subrc = 0. " 将关键参数存入内存ID，供弹窗读取 IMPORT gs_selected_row FROM MEMORY ID 'ZMM_PO_DETAIL_CTX'. " 调用弹窗屏幕 CALL SCREEN 200 STARTING AT 10 10 ENDING AT 60 20. ENDIF. WHEN OTHERS. ENDCASE. CLEAR ok_code. ENDMODULE.

这里用IMPORT/EXPORT MEMORY ID传递上下文，比全局变量更安全，避免多用户并发时数据污染。

3.3 弹窗屏幕（200）的ALV初始化：构建独立handle

弹窗PBO：

*&---------------------------------------------------------------------* *& Module STATUS_0200 OUTPUT *&---------------------------------------------------------------------* MODULE status_0200 OUTPUT. SET PF-STATUS 'ZMM_PO_DETAIL'. SET TITLEBAR 'ZMM_PO_DETAIL'. " 1. 从内存读取上下文 IMPORT gs_selected_row FROM MEMORY ID 'ZMM_PO_DETAIL_CTX'. IF sy-subrc <> 0. MESSAGE '上下文丢失' TYPE 'E'. ENDIF. " 2. 根据物料号查询库存明细（模拟） PERFORM get_stock_detail_data USING gs_selected_row-matnr CHANGING gt_stock_data. " 3. 构建独立的字段目录（绝对不能复用gt_header_fcat！） PERFORM build_stock_fieldcat CHANGING gt_stock_fcat. " 4. 初始化独立的layout结构体 CLEAR gs_stock_layout. gs_stock_layout-no_toolbar = space. gs_stock_layout-colwidth_opt = 'X'. gs_stock_layout-cwidth_opt = 'X'. gs_stock_layout-sel_mode = 'D'. " 单选模式（弹窗常用） gs_stock_layout-zebra = 'X'. gs_stock_layout-i_callback_pf_status_set = 'SET_PFSTATUS_DETAIL'. gs_stock_layout-i_callback_user_command = 'USER_COMMAND_DETAIL'. gs_stock_layout-i_callback_top_of_page = 'TOP_OF_PAGE_DETAIL'. " 5. 调用ALV（同样i_screen = sy-dynnr） CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY_LVC' EXPORTING i_callback_program = sy-repid i_screen = sy-dynnr i_grid_title = |库存明细 - { gs_selected_row-matnr }| i_structure_name = 'MARD' " 库存表结构 is_layout = gs_stock_layout it_fieldcat = gt_stock_fcat i_save = 'U' " 用户级保存（不覆盖全局） i_default = 'X' TABLES t_outtab = gt_stock_data EXCEPTIONS program_error = 1 OTHERS = 2. IF sy-subrc <> 0. MESSAGE '弹窗ALV显示失败' TYPE 'E'. ENDIF. ENDMODULE.

对比主屏和弹窗的代码，你会发现核心差异：

这就是handle独立性的物理体现——每个屏幕都有自己的“身份证”（callback_program+screen）、自己的“控制台”（layout）、自己的“状态箱”（data+fieldcat）。

3.4 弹窗关闭时的handle清理：避免内存泄漏与状态污染

很多开发者忽略一点：ALV在屏幕关闭时并不会自动释放其内部对象。如果用户频繁打开/关闭弹窗，ALV会持续占用内存，最终导致系统变慢甚至dump。正确的做法是在弹窗PAI中捕获“取消”或“确认”事件，并手动清理。

弹窗PAI：

*&---------------------------------------------------------------------* *& Module USER_COMMAND_0200 INPUT *&---------------------------------------------------------------------* MODULE user_command_0200 INPUT. CASE ok_code. WHEN 'BACK' OR 'CANCEL' OR 'EXIT'. " 清理内存ID，避免残留 FREE MEMORY ID 'ZMM_PO_DETAIL_CTX'. " 关闭屏幕 LEAVE TO SCREEN 0. WHEN 'SAVE'. " 保存操作... LEAVE TO SCREEN 0. WHEN OTHERS. ENDCASE. CLEAR ok_code. ENDMODULE.

FREE MEMORY ID是必须的。此外，如果ALV中启用了i_save = 'U'，用户保存的布局会存储在用户参数里（T000表），无需额外清理；但如果用了i_save = 'A'，则需在程序退出前调用CL_GUI_ALV_GRID=>CLEANUP( )，不过REUSE_ALV_GRID_DISPLAY_LVC是函数模块，不暴露grid对象引用，因此更稳妥的做法是：永远为弹窗使用i_save = 'U'，主屏用i_save = 'A'，并在主屏退出时用FREE MEMORY ID清除所有相关上下文。

实操心得：在主屏幕的LEAVE PROGRAM或LEAVE TO SCREEN 0前，统一执行FREE MEMORY ID 'ZMM_*'，用通配符清理所有相关内存块。这是保障多屏幕ALV长期稳定运行的隐形守则。

4. handle参数详解：那些文档里没写的23个关键字段真相

is_layout结构体是handle的核心载体，其字段多达上百个。但真正影响多屏幕独立性的，是其中约23个关键字段。官方文档往往只给定义，不讲陷阱。下面逐个拆解这些字段在多屏幕场景下的真实行为。

4.1 必须显式设置的7个生存字段

这些字段一旦为空或设错，ALV直接无法启动或行为异常：

注意：i_default = 'X'并非“使用默认值”，而是“启用默认布局机制”。如果不设，ALV不会自动应用任何列宽或排序，即使你fieldcat里写了outputlen，它也忽略。

4.2 影响状态隔离的8个布局字段

这些字段决定ALV在不同屏幕间的“人格”是否独立：

特别提醒cwidth_opt和colwidth_opt的区别：前者是“记忆”，后者是“优化”。cwidth_opt = 'X'时，ALV会把用户拖拽后的列宽存入et_fieldcat的outputlen字段，并在下次调用时读取；colwidth_opt = 'X'时，ALV会扫描该列所有数据，取最长字符串长度+2作为初始列宽。两者可同时启用，效果叠加。

4.3 那些“看似可选，实则致命”的8个高级字段

这些字段在单屏时可忽略，但在多屏幕协同中，是解决具体业务痛点的关键：

其中i_callback_handle_data是处理“数据联动”的神器。比如在MIRO拆分增强中，主ALV显示凭证行，弹窗ALV显示拆分明细。当用户在弹窗ALV里修改某行的“拆分金额”时，你需要实时更新主ALV的“已拆分总额”。这时在HANDLE_DATAFORM里，你可以拿到变更前后的数据，计算差额，并通过EXPORT到内存ID通知主屏刷新。

实操技巧：HANDLE_DATAFORM的接口是FORM handle_data CHANGING p_data TYPE STANDARD TABLE，p_data是变更后的整张表。不要在里面做耗时操作（如DB UPDATE），只做内存计算和状态标记，DB操作放到USER_COMMAND的SAVE功能码里执行。

5. 常见崩溃现场还原：5个让ABAP顾问彻夜难眠的handle故障链

再完美的设计，也架不住生产环境的千奇百怪。下面5个故障，是我过去三年在客户现场亲手排查、修复的真实案例。每个都附带完整的故障链路、根因分析和永久解决方案。

5.1 故障1：弹窗ALV双击无反应，PAI里ok_code始终为空

现象：用户在弹窗ALV里双击某行，屏幕没有任何跳转，调试发现PAI的ok_code是空，USER_COMMANDFORM根本没被调用。

排查链路：

1. 检查is_layout-i_callback_user_command是否赋值 → 正确，为'USER_COMMAND_DETAIL'；
2. 检查USER_COMMAND_DETAILFORM是否存在 → 存在，语法正确；
3. 检查GUI STATUSZMM_PO_DETAIL是否分配了&IC1（双击）功能码 → 已分配；
4. 检查ZMM_PO_DETAIL的&IC1是否指向正确程序 → 指向ZMM_ALV_MAIN，而非弹窗程序！

根因：GUI STATUS是全局资源。ZMM_PO_DETAILSTATUS在SE41里创建时，被错误地分配给了主程序ZMM_ALV_MAIN，导致双击事件被发送到主程序的USER_COMMAND，而主程序里没有处理弹窗逻辑。

永久方案：

• GUI STATUS必须与i_callback_program严格一致；
• 在SE41中，为每个屏幕创建独立STATUS，并在“Attributes”页签里将“Program”字段设为对应程序名；
• 使用SET PF-STATUS 'ZMM_PO_DETAIL' IN PROGRAM 'ZMM_ALV_DETAIL'（如果弹窗是独立程序）。

5.2 故障2：主屏ALV列宽记忆失效，每次打开都重置

现象：用户把“凭证号”列拖得很宽，关闭屏幕再打开，列宽恢复默认。

排查链路：

1. 检查is_layout-cwidth_opt是否为'X'→ 是；
2. 检查et_fieldcat中outputlen字段是否被修改 → 是，用户拖拽后outputlen已更新；
3. 检查ALV调用时是否传入了更新后的et_fieldcat→ 否！PBO里et_fieldcat是gt_header_fcat，但gt_header_fcat在ALV调用前未被IMPORT，仍是初始值。

根因：cwidth_opt = 'X'时，ALV会把修改后的outputlen写回et_fieldcat参数。但这个参数是CHANGING，必须在ALV调用后，由你的程序主动EXPORT到内存或存入全局变量，否则下次调用还是用旧值。

永久方案：

• 在ALV调用后，立即EXPORT gt_header_fcat TO MEMORY ID 'ZMM_HEADER_FCAT'；
• 在PBO开头，IMPORT gt_header_fcat FROM MEMORY ID 'ZMM_HEADER_FCAT'；
• 或者更简单：每次PBO都重新BUILD fieldcat，把用户偏好存入TVARV表（用户变量）。

5.3 故障3：弹窗ALV导出Excel，文件里全是乱码（ABAP Unicode解码问题）

现象：点击导出按钮，生成的Excel打开后中文是方块或问号。

排查链路：

1. 检查系统是否Unicode → 是（S/4HANA必Unicode）；
2. 检查it_outtab内表字段类型 →CHAR和STRING混用；
3. 检查et_fieldcat中scrtext_l（长文本）字段 → 为STRING类型，但ALV导出时未正确编码。

根因：REUSE_ALV_GRID_DISPLAY_LVC在Unicode系统中，对STRING类型字段的导出处理有缺陷。它会把STRING当作字节流写入，而Excel期望UTF-16。解决方案是强制转换为CHAR。

永久方案：

• 在导出前，遍历it_outtab，将所有STRING字段用CONVERT STRING TO CHARACTER转换；
• 或者更彻底：在BUILD fieldcat时，对STRING字段，设置fieldcat-outputlen = 100，并确保内表对应字段为CHAR LENGTH 100；
• 网络热词里的abap unicode解码，本质就是这个转换过程。

5.4 故障4：ALV状态栏按钮文本不显示，全是功能码（如&XX1）

现象：GUI STATUS里按钮文本设为“导出”，但ALV工具栏显示&XX1。

排查链路：

1. 检查STATUS里按钮文本 → 正确，为中文；
2. 检查SET_PFSTATUSFORM里是否调用SET PF-STATUS→ 是；
3. 检查SET PF-STATUS语句是否带EXCLUDING→ 是，且排除了&XX1。

根因：EXCLUDING参数排除了功能码，但ALV的工具栏按钮是动态生成的，EXCLUDING只影响标准按钮，对ALV自定义按钮无效。真正原因是：SET_PFSTATUSFORM里，SET PF-STATUS必须在SET TITLEBAR之后调用，且不能有EXCLUDING。

永久方案：

• SET_PFSTATUSFORM里，只写：

  SET PF-STATUS 'ZMM_PO_DETAIL'. SET TITLEBAR 'ZMM_PO_DETAIL'.

• 所有按钮控制（启用/禁用）在USER_COMMAND里用SET PF-STATUS ... EXCLUDING动态处理；
• 确保STATUS里按钮文本是简体中文，且程序属性里“Language”设为ZH。

5.5 故障5：多用户并发时，弹窗ALV显示其他用户的数据

现象：用户A打开弹窗看到物料1001的库存，用户B同时打开看到物料1001的库存，但用户B实际想看1002。

排查链路：

1. 检查内存IDZMM_PO_DETAIL_CTX→ 是全局内存，所有用户共享；
2. 检查IMPORT/EXPORT是否带用户标识 → 否，直接EXPORT gs_row TO MEMORY ID 'CTX'；
3. 检查ALV数据查询逻辑 →SELECT * FROM mard WHERE matnr = gs_row-matnr，但gs_row来自全局内存。

根因：EXPORT TO MEMORY ID是系统级内存，不区分用户。用户A写入，用户B读取，必然串数据。

永久方案：

• 改用EXPORT TO DATABASE INDX(ST) ID 'ZMM_CTX'，其中ST是用户标识（sy-uname）；
• 或者更简单：用cl_gui_alv_grid=>get_frontend_layout( )获取当前ALV对象，再用set_frontend_layout( )设置，但这需要获取grid对象，REUSE函数不提供；
• 最佳实践：永远用EXPORT TO DATABASE替代EXPORT TO MEMORY，并带上用户标识。

最后分享一个小技巧：在ALV调用前，加一行WRITE:/ 'Handle Debug:', sy-repid, sy-dynnr.，然后在系统日志里搜索，可以快速定位是哪个屏幕、哪个程序在调用ALV。这比在几十个FORM里埋点高效得多。

我在实际使用中发现，90%的ALV多屏幕问题，根源都在handle参数的“身份”“控制”“状态”三重契约被破坏。只要守住i_callback_program = sy-repid、i_screen = sy-dynnr、独立数据+独立fieldcat+独立layout这三条铁律，再复杂的多屏协同也能稳如磐石。那些网络热词里反复出现的sap miro拆分增强、abap mm01 mm02 mm03物料主数据新屏幕增强，本质上都是这个handle契约在不同业务场景下的变形应用。理解它，你就拿到了ABAP ALV世界的钥匙。