1. 为什么我会盯上“动态列显示”这个需求做ABAP开发的人应该都碰到过这类需求用户跑完报表说“这列我不想看太占地方”“那列能不能按订单类型随时切换”“导出Excel的时候只要我勾选的字段”。接到这种需求先把话说明白——不是布局调整不是字段顺序微调是在程序运行期间根据某种条件动态决定ALV表格显示哪些列、隐藏哪些列甚至临时生成一批新列。我最早处理这个需求是在一套对外的销售分析报表上。业务方每个月要看的维度都不一样上月看“订单量销售额退货率”这月就变成了“销售额同比环比毛利”。一开始我写死了字段目录结果每月跟着改代码、重新传输业务方还嫌慢。后来我被逼着把字段目录的构建从“写死”改成“运行时算出来”那版报表上线之后舒服多了也让“动态列显示”成了我做ALV列表类程序时默认考虑的第一件事。这篇文章我不想复述标准文档更多是想把字段目录的动态构造逻辑、运行时切换列的机制、性能上容易踩的坑、以及真实项目里怎么排错串一遍。如果你正准备改造一个只能显示固定列的ALV程序或者想做一个可配置列显示的通用报表基架这篇应该能直接给你省下不少试错时间。先给还不太熟的读者打个底。ALV全称是SAP List Viewer在ABAP里最常见的两种实现方式一种是函数式ALV通过REUSE_ALV_GRID_DISPLAY把数据甩给ALV控件字段目录用LVC_T_FCAT这个内表控制另一种是面向对象的ALV以CL_GUI_ALV_GRID为核心事件处理更灵活。动态列显示这件事两种方式都能做核心都绕不开LVC_T_FCAT——也就是ALV的字段目录它对用户来说叫“列设置”对开发来说叫“字段目录”。2. 字段目录FIELDCAT的动态构建逻辑先把列算出来再显示2.1 从“写死”到“动态计算”的第一步分清静态列和动态列很多ABAP开发者对ALV字段目录的理解就停留在“照着结构拖字段进去”然后写个BUILD_FIELDCAT表单把要显示的字段一条条APPEND。这种方式维护简单但扩展性极差。真正做动态列显示第一件事是拆字段来源静态列任何条件下都要显示的列比如单据号、日期、状态标识。动态列根据筛选条件、用户选择、权限角色、甚至某个主数据配置决定哪些列进入字段目录。我习惯先在程序里定义一张“列配置内表”格式大致是字段名、ALV列标题、输出长度、是否合计、是否可编辑、可见性条件、排序位置。这个内表相当于一个列定义仓库后续构建字段目录时就直接从仓库里按条件捞。TYPES: BEGIN OF ts_col_config, fieldname TYPE lvc_fname, coltext TYPE lvc_txtcol, outputlen TYPE lvc_outlen, do_sum TYPE char1, edit TYPE char1, visible TYPE char1, X显示 空隐藏 position TYPE i, END OF ts_col_config.有了这个仓库构建字段目录就变成了一个“筛选排序”的过程而不是手工一条条写APPEND。这套思路在很多老项目里其实已经有了雏形比如用DD03L捞表字段自动生成字段目录只是没有把“动态”作为一等公民去设计。2.2 运行时按条件生成FIELDCAT而不是预先固定动态列的一个典型场景是报表筛选界面上用户勾选“是否显示折扣率”勾了就显示不勾就不显示。代码层面的做法很直接——先让用户把选择条件存到内存比如一个GT_SEL内表然后构建字段目录时逐条判断。PERFORM build_fieldcat USING gt_col_config CHANGING gt_fieldcat. FORM build_fieldcat USING pt_config TYPE tt_col_config CHANGING pt_fcat TYPE lvc_t_fcat. LOOP AT pt_config INTO DATA(ls_config) WHERE visible X. 只取需要显示的列 DATA(ls_fcat) VALUE lvc_s_fcat( fieldname ls_config-fieldname coltext ls_config-coltext outputlen ls_config-outputlen do_sum ls_config-do_sum edit ls_config-edit ). 如果涉及自建字段必须指定 ref_table/ref_field 或 inttype/intlen APPEND ls_fcat TO pt_fcat. ENDLOOP. 按 position 排序 SORT pt_fcat BY position. ENDFORM.这一段的重点是字段目录的每一行都是运行时算出来的结果。业务规则变了就改列配置内表或者改判断逻辑显示层不用动。2.3 动态列不仅仅是“隐藏”还包括“临时拼接出来的列”刚开始做动态列显示的人容易把“动态”只理解为“从一堆既有字段里挑几个显示”。但这只做了一半。真正的动态列还包括程序运行时根据业务逻辑现场计算出来的列。比如销售分析报表里有一列“订单毛利率”这个字段在数据库表里根本不存在是程序算出来的。处理这种列关键点在字段目录里要给它定义好数据类型、长度、小数位。否则ALV不知道这一列该显示多宽、能不能合计。DATA(ls_fcat) VALUE lvc_s_fcat( fieldname GROSS_MARGIN coltext 毛利率 inttype C intlen 20 decimals 2 ). 如果是数字型计算字段最好绑定一个参考结构或参考字段 ls_fcat-ref_table KNA1. ls_fcat-ref_field KUNNR.这里有个容易忽略的细节计算列如果只是内表里临时加的字段而内表的行类型是BEGIN OF自定义的构建字段目录时必须准确填写INTTYPE、INTLEN这些技术属性。漏了ALV要么显示成乱码要么直接报“字段目录无效”的错误。我见过好多新手在这个地方卡一晚上。2.4 动态列与ALV布局VARIANT的配合做动态列绕不开一个交互层面的东西——用户调整列宽、顺序、隐藏列之后ALV支持把这种布局保存为变式VARIANT。当你的字段目录是动态生成的就要特别小心用户保存的变式里记录的列可能和你这次运行时生成的列对不上。我的经验是动态列程序建议给ALV设置I_SAVE A或U允许用户保存布局但在字段目录里为每个字段设置好SP_GROUP组代码或者NO_OUT初始隐藏。这样即使变式中藏着一些本次运行时已经不存在的历史列ALV也会安静地忽略掉不会报错。如果完全不想让用户保存变式就设置I_SAVE 。但做业务报表时我还是倾向于保留变式因为用户对列宽、冻结列这些个性化设置的需求非常真实你不能让每个用户每次跑报表都重新拉一遍列宽。3. 运行时切换列的几种实现方式哪种场景用哪种别搞混3.1 方式一重新生成字段目录并刷新ALV最稳如果动态列的变化发生在用户触发某个事件之后比如在ALV工具栏上加一个按钮“列过滤”点开弹窗勾选列确定后ALV立刻更新这是最常用的场景。这种实现的核心动作是 1. 重新构建字段目录 PERFORM build_fieldcat CHANGING gt_fieldcat. 2. 把新的字段目录交给ALV CALL METHOD go_grid-set_frontend_fieldcatalog EXPORTING it_fieldcatalog gt_fieldcat. 3. 刷新ALV显示 CALL METHOD go_grid-refresh_table_display.用函数式ALV的话方式有点区别。函数式ALV不支持运行中随意更换字段目录然后原地刷新这么直接一般做法是把数据重新甩给REUSE_ALV_GRID_DISPLAY传新的字段目录进去。因为函数式ALV内部会重新构建ALV控件相当于整个刷新一遍。OO ALV之所以推荐用set_frontend_fieldcatalog是因为它不会销毁整个ALV控件只是替换字段目录保留用户的滚动位置、排序状态体验好很多。这也是我在新项目里倾向OO ALV的一个原因。3.2 方式二使用get_frontend_fieldcatalog拿到当前列再局部改状态有时候不希望整个字段目录推倒重建只想对单个字段做“显示/隐藏”切换。比如点表头右键菜单“显示/隐藏列”或者某个字段根据勾选框实时切换。这时可以先从ALV控件里把当前字段目录取回来CALL METHOD go_grid-get_frontend_fieldcatalog IMPORTING et_fieldcatalog gt_fieldcat. LOOP AT gt_fieldcat ASSIGNING FIELD-SYMBOL(fs_fcat) WHERE fieldname DISCOUNT. IF gv_show_discount X. fs_fcat-no_out . ELSE. fs_fcat-no_out X. ENDIF. ENDLOOP. CALL METHOD go_grid-set_frontend_fieldcatalog EXPORTING it_fieldcatalog gt_fieldcat. CALL METHOD go_grid-refresh_table_display.注意NO_OUT这个字段在字段目录里是专门用来控制“初始隐藏列”的。它和TECH技术列不同NO_OUT只是不在界面上显示但字段本身还在TECH则完全从ALV界面里拿掉连隐式存在都没有。处理动态列时这两者别混用。3.3 方式三利用ALV自带的列代号设置手动列过滤其实SAP ALV自带了一套“显示/隐藏列”的用户界面用户在ALV上右键 → 列设置可以勾选显示哪些列。这套功能不需要开发写一行代码只要在调用ALV时允许保存布局用户自己就能玩。那为什么还要自己开发动态列两个原因一是用户希望列集合随参数变化而不是自己手动调比如“客户主数据视图下自动隐藏毛利列”二是有些列权限敏感不能让用户自己调出来必须在程序里做限制。所以真实的项目通常是混着用默认字段目录由程序动态控制同时允许用户在程序控制的范围里进一步手动调列宽、顺序、显隐。实践下来这个组合最舒服既省开发量又不失灵活性。3.4 函数式ALV和面向对象ALV在动态列上的关键差异这点值得单独拎出来说。很多ABAP开发者仍然习惯函数式ALV因为写起来短、老代码多。但如果你确定要做一个“显示列会动态变化”的报表我强烈建议用OO ALV。理由是函数式ALV每刷新一次字段目录几乎等于重新调一次REUSE_ALV_GRID_DISPLAY你的TAB_EVENTS、事件处理、自定义工具栏全都得重新挂一遍。逻辑一多函数式ALV那种基于全局栈的写法特别容易埋坑。OO ALV则把控件实例握在手里想改字段目录、想改显示数据、想弹自定义事件处理都是围绕一个对象做操作心智负担低很多。4. 动态列背后的关键难点技术属性、排序、合计都得跟着走4.1 字段目录的“参照”问题是动态列最大的暗坑固定列显示的时候字段目录直接参考内表结构REF_TABLE、REF_FIELD由ALV自动推断基本不用管。一旦列开始“动态生成”你往往手动构建LVC_S_FCAT行类型、列宽、小数位、货币单位这些技术属性如果没有正确指定ALV要么显示成####要么排序错乱要么合计值直接被忽略。以我自己项目里出现过的场景为例。我需要在ALV里动态加一列“币种转换后的金额”数据来自汇率计算内表行类型里定义了一个TOTAL_AMOUNT TYPE CURRENCY字段。构建字段目录时我一开始只填了fieldname和coltext没填ref_table和ref_field结果ALV显示出来全是( )合计算不对。后来补上ls_fcat-ref_table BKPF. ls_fcat-ref_field WRBTR. ls_fcat-cfield WAERS. 货币字段 ls_fcat-currency WAERS.问题立刻消失。所以写动态列你的字段目录生成逻辑里一定要有一套完整的映射规则——哪些字段参照哪个表哪个字段金额字段的货币单位挂在哪个字段上绝不能裸写。这个不解决动态列就是空中楼阁。4.2 动态排序与列顺序控制动态列难免涉及“列顺序”。字段目录内表的排列顺序就是ALV显示的从左到右顺序。如果你希望动态列的插入位置固定比如“动态毛利率列永远显示在销售费用列的右边”那么在构建字段目录时就要控制好position。我常用的做法是给列配置内表维护一个POSITION字段构建时按它排序。但如果你的项目里有标准ALV变式介入变式中记录的是列名和顺序可能与动态生成的字段目录不一致。这时要以LVC_S_FCAT-SP_GROUP分组控制为基准不要把变式的顺序当成动态列顺序的唯一依据。真正生产项目中动态列的顺序经常被业务方挑剔“为什么这列跑到那列后面去了”所以这真不是小事。一开始就把顺序规则设计进列配置仓库后面省很多沟通成本。4.3 动态列与合计行的联动ALV底部可以显示合计行。固定列合计的时候很简单字段目录里DO_SUM打上X就行。但动态列场景下哪些列显示合计本身也是一个动态决策。比如毛利率列显示出来时业务方可能希望看到加权平均毛利率而不是简单SUM。处理加权平均的官方思路通常有两种一种是字段目录不勾DO_SUM利用CL_ALV_TABLE_CREATE之后挂ON_AFTER_DATA事件在事件里手工写合计行数据另一种是设置LVC_S_FCAT-EMP_FIELDNAME或者使用TOTALS_ONLY这类选项把单一字段合计委托给ALV。我的实际建议是真正需要业务逻辑介入的合计列优先使用ON_AFTER_PRINT或ALV合计事件去精细控制不要把期望寄托在ALV默认组件上。动态列动态合计组合起来是最容易出幺蛾子的地方等用户上线后才发现“这列竟然没有合计”你会很被动。4.4 工具字段与隐藏业务列的取舍动态列显示还有一类特殊需求列本身存在用于内部逻辑但不展示给用户。比如ALV行上要根据隐藏的“物料组”字段做后续双击跳转这个字段不需要显示在界面上。字段目录中有一个TECH字段可以打上X把该字段作为技术字段从界面隐藏但它仍存在于显示用内表中可以参与ALV内部事件。还有一个NO_OUT表示列存在但默认不输出用户可以通过列设置调出来。我遇到过一个场景某个字段在标准报表中永远是NO_OUT但业务方希望个别用户能自己把它调出来核对数据。当时我用TECH NO_OUT X做到了——默认不显示但列清单里还能看到这一列勾选后可以显示。如果一刀切用TECHX用户就永远看不到这列了。这个经验告诉我说设计动态列方案时要想清楚列是“必须不可见”还是“默认不可见”。这两种要求的实现方式不一样而且改起来容易一开始想反了后面业务方会一直纠结。5. 一个实际例子销售分析报表的动态列控制完整链路5.1 需求背景与配置表设计为了把前面这些点串起来我拿实际项目里的简化版本做个示例。需求是某销售分析报表有5个固定字段订单号、客户、订单日期、金额、货币 5个可选字段毛利率、折扣率、销售区域、订单状态、是否紧急订单。用户通过选择屏幕上的复选框选择显示哪些可选字段。我把列配置库存放在程序内部的一个GT_COL_CONFIG内表里其中每一行对应一个字段的定义。程序初始化时填充这个内表CLEAR gt_col_config. APPEND VALUE #( fieldname ORDER_NO coltext 订单号 visible X position 1 ) TO gt_col_config. APPEND VALUE #( fieldname CUSTOMER coltext 客户名称 visible X position 2 ) TO gt_col_config. APPEND VALUE #( fieldname ORDER_DATE coltext 订单日期 visible X position 3 ) TO gt_col_config. APPEND VALUE #( fieldname TOTAL_AMOUNT coltext 订单金额 visible X position 4 do_sum X ) TO gt_col_config. APPEND VALUE #( fieldname CURRENCY coltext 币种 visible X position 5 ) TO gt_col_config. IF s_show-gross X. APPEND VALUE #( fieldname GROSS_MARGIN coltext 毛利率 visible X position 6 ) TO gt_col_config. ENDIF. IF s_show-disc X. APPEND VALUE #( fieldname DISCOUNT_RATE coltext 折扣率 visible X position 7 ) TO gt_col_config. ENDIF. ...这种写法的一个好处是加一个新的可选列只需在配置内表里加一行字段目录生成逻辑完全不用动。如果哪天可选列增加到30个也只是配置和界面控件同步扩展。5.2 数据准备与字段目录生成数据准备阶段除了从底层表取数据还有一个关键动作——为每个动态计算字段赋值。比如毛利率LOOP AT gt_alv ASSIGNING FIELD-SYMBOL(fs_alv). IF fs_alv-amount 0. fs_alv-gross_margin ( fs_alv-revenue - fs_alv-cost ) / fs_alv-amount * 100. ELSE. fs_alv-gross_margin 0. ENDIF. ENDLOOP.然后调用前面说的build_fieldcat把GT_COL_CONFIG里visible X的字段转成GT_FIELDCAT。5.3 刷新时保留用户交互状态在选择了屏幕里改变复选框重新执行按钮程序要重建字段目录然后刷新ALV。这个环节OO ALV可以直接用set_frontend_fieldcatalogrefresh_table_display用户体验是勾选变化ALV列立即更新但当前焦点行、滚动条位置、排序状态基本保留。函数式ALV在这个场景下会让用户回到表格顶部体验相对差一些。所以我在标题里就把这个例子定位为“用什么方案更合理”实际落地时我确实把类似报表从函数式ALV改成了OO ALV用户满意很多。5.4 这个例子里遗漏过的一个问题显示字段不来自一个数据源还是这个销售报表最初设计时我犯过一个错误——毛利率、折扣率、销售区域这几个字段分别来自不同的数据库表。我在主内表里定义了所有字段但数据填充时没有关联主键导致ALV里几列数据错位。后来排查才发现问题不在字段目录而在底层数据模型根本没把字段在一个行类型里对齐。动态列显示容易让开发者把注意力集中在“列”上忽略了“行”才是根本。无论怎么动态显示ALV的数据源内表必须是一个完整行类型每个字段都有明确来源动态列只是在这个基础上挑列展示。这个意识一旦建立很多后续问题都能避免。6. 动态列程序调试实战字段目录无效、列错位、合计不准的完整排查链路6.1 “字段目录无效”是怎么一步步定位出来的这个报错所有做ALV的人基本都见过。静态列时出现得少动态列时频繁出现因为字段目录是拼出来的总有字段属性没拼全。我通常的排查链路是先检查GT_FIELDCAT里是否有空值字段名或者FIELDNAME拼错、大小写不一致。ABAP字段名通常是大写但动态拼字段名时容易引入前导空格或小写字母。检查是否有两个字段重复使用同一个FIELDNAME尤其是动态列和静态列字段重名。检查字段目录里的技术属性有没有异常值比如INTLEN 0、INTTYPE为空。可以用DESCRIBE FIELD或直接输出内表内容到屏幕把字段目录在调试器里展开看看。检查REF_TABLE和REF_FIELD对应的表字段是否确实存在于字典中。动态列如果参照了一个被删改的字段ALV初始化时会直接失败。定位手段上我最常用的是在调用ALV之前打一个断点把GT_FIELDCAT完整内容贴到测试环境里肉眼扫一遍。动态列字段多的时候写个循环输出字段名和属性到屏幕也比瞎猜高效LOOP AT gt_fieldcat INTO DATA(ls_fcat). WRITE:/ ls_fcat-fieldname, ls_fcat-ref_table, ls_fcat-ref_field, ls_fcat-inttype, ls_fcat-intlen. ENDLOOP.6.2 列错位和数据串列的具体例子另一个高频问题是“列错位”——ALV显示的A列实际数据内容是B列的。这类问题在动态列里太常见了原因是字段目录里字段名和内表组件名不匹配尤其涉及嵌套结构、别名时。比如内表行类型是BEGIN OF ts_alv, order TYPE vbeln, customer TYPE kunnr, END OF ts_alv但字段目录里习惯性地写了FIELDNAME ORDER_NO或ORDER_NR这一列在运行时就是初始值没有任何报错看起来整列都是空的。处理方法是建立“字段名映射表”或者直接用结构组件名动态生成字段目录DATA(lo_struct) CAST cl_abap_structdescr( cl_abap_typedescrdescribe_by_name( TS_ALV ) ). LOOP AT lo_struct-components INTO DATA(ls_comp). 用 ls_comp-name 作为 fieldname保证和内表组件完全一致 ENDLOOP.这个方法非常稳适合字段多的场景我后来做动态列基架就一直用这套。6.3 合计不准的隐蔽原因回到前面提到的动态合计问题。排查合计不准时先别怀疑ALV先检查数据内表中该列的取数逻辑。动态列通常有部分行是空值或特殊逻辑ALV的DO_SUM会根据所有被SUM的行汇总如果某个字段在部分行是CHAR类型ALV可能直接不合计或者给你一个头大的字符拼接值。还有一个坑LVC_S_FCAT-DO_SUM和LVC_S_FCAT-NO_SUM是互斥的但很多人只设置了DO_SUM没去管某些行的NO_SUM是否被重置。如果前一次刷新用的是另一个字段目录字段目录对象里的NO_SUM值可能残留就会导致合计行为异常。所以刷新字段目录时我建议每个字段都显式把DO_SUM、NO_SUM、NO_OUT、TECH这四个属性全部赋一轮初值不要指望旧目录的默认状态。6.4 为什么我推荐加一层“字段目录校验函数”实际项目跑久了动态列多了我慢慢养成了一个习惯在把字段目录交给ALV之前先跑一个内部校验函数。这个函数不干别的就把传入字段目录逐条检查字段名非空、技术属性合法、重复字段名提示、DOI_SUM冲突标识。看起来麻烦但真的能救场。有一次我重构一个老报表把字段目录构建逻辑从函数式ALV迁移到OO ALV迁移完第一版一直报“某个字段目录条目无效”整个ALV白屏。我用校验函数检查后发现是一个动态计算字段的REF_TABLE写错了参照了一个不存在的结构。这种错误在运行期特别难查因为报错信息太笼统了但如果你有一层显示前的校验10秒就能定位。7. 性能与可维护性动态列设计对数据量和传输的影响7.1 大字段目录对接口调用和内存的影响动态列不只是“显示层”的事。字段目录最终要传给前端ALV控件在Web版SAP环境比如SAP GUI for HTML、Fiori化封装里这意味着前端要构建和渲染一个可能几十上百列的表格。列越多前端渲染成本越高、网络传输越大。如果报表数据量大——比如上万行、上百列——动态列配置会让整个报表从“点一下出结果”变成“转圈转半天”。我的优化经验是动态列生成后根据用户显示需求精简字段目录在传给ALV之前把不需要的字段直接过滤掉而不是永远保留一个全量字段目录。数据内表受限于行类型无法动态裁剪但字段目录完全可以裁剪这让前端只渲染用户关心的列。7.2 动态列报表的缓存与命中率SAP ALV的REUSE_ALV_GRID_DISPLAY有个概念叫“布局缓存”Layout Cache。动态列如果频繁变化可能让变式缓存命中率下降——因为每次运行生成的列集合不同用户保存的变式可能和当前布局对不上。一种做法是把动态列的选择条件作为变式文件名的一部分比如用户勾选“显示毛利率”时保存一个变式SALES_WITH_GROSS没勾选时保存SALES_WITHOUT_GROSS。这样缓存不会互相打架用户在不同视图之间切换也不丢布局。做法看起来有点笨但在实际项目里非常实用。7.3 动态列功能模块化的工程建议最后提一点工程层面的东西。做动态列显示不要把逻辑都塞进一个报表的START-OF-SELECTION里。我会把动态列功能拆成几个可复用的“列配置对象”列定义仓库内表填充逻辑字段目录构建器输入列配置输出LVC_T_FCAT字段目录校验器显示前校验ALV刷新封装set_frontend_fieldcatalogrefresh_table_display这几个模块解耦之后新报表接入动态列只需要定义自己的列配置仓库构建器、校验器、刷新封装都是复用现成的。这一套我在内部做了两次架构迭代才稳定下来早期版本把配置和构建逻辑写在一起改一个字段目录规则就得动整个构建器极其痛苦。8. 我现在做动态列显示的几个固定习惯当作给你踩坑后的备忘真正把动态列显示做进多个生产项目之后我逐渐形成了一套固定习惯每一条都是从踩坑里换来的第一条永远先定义列配置模型再写字段目录生成。不要在FORM build_fieldcat里临时拼字段那样每改一次需求你都要翻一遍构建逻辑。第二条所有动态列字段的技术属性最好逐一显式指定不依赖ALV默认推断。尤其是INTTYPE、INTLEN、DECIMALS、REF_TABLE、REF_FIELD。宁可多写不要出事后再补。第三条刷新字段目录前手动清空新旧状态的属性残留。上面提到的NO_OUT、TECH、DO_SUM、NO_SUM都要重新赋值。ALV控件本身会保存上一次的状态不做清理就会出现“旧列隐藏了但新列也不显示”之类的怪现象。第四条动态列配用户可保存变式时一定测试“旧变式 新列组合”的兼容性。用户的环境里可能同时存在七八个历史变式你不去主动清理ALV会按自己的逻辑合并新旧结果往往不是你预期的。第五条动态列不只是开发层的活要提前设计好业务元数据。比如“毛利率”这一列的显示标题、格式、顺序、合计规则最好有张配置表存起来而不是散落在代码里。有了这张配置表业务人员自己也可以改列名你不用频繁改程序。回到我最开始说的那个销售分析报表。最终方案就是用户在选择屏幕里勾选可选列程序根据勾选结果动态构建字段目录ALV刷新后只展示用户关心的列同时允许用户保存不同勾选组合下的布局变式。上线后业务方再也没提过“帮我加一列”的需求因为加列的入口已经在他们手上了。如果你正在做一个ABAP报表或者ALV工具建议先往这个方向想一想你的字段目录是“写死的”还是“算出来的”如果还是写死的至少先抽出构建函数把列定义从程序逻辑中分离出来。做到这一步后面无论是做动态显隐还是做权限控制列都会顺利得多。