4GL+T100开发实战：从语法基础到性能优化与调试避坑指南

我最初接手一整套T100系统的时候，心里其实有点打鼓：市面上讲Java、Python、C#的资料一抓一大把，可专门讲4GL+T100开发的文章就像稀有物种，能找到的往往只有官方手册的片段，更多时候是靠老同事一句一句带、一个坑一个坑踩出来的。这套组合虽然不像主流语言那样“网红”，但在制造、流通企业的ERP后端里，它依然是能扛事的那个。干了这些年，我把各种零散的写法、踩过的坑、验证过的方法慢慢收集到一起，就有了这篇文章。它不保证能把你的4GL水平从零拉到专家，但至少能让你在写常用逻辑、画面、报表和批次作业的时候，少走几步弯路。

1. 先弄明白：4GL在T100里到底扮演什么角色

1.1 4GL不是“老古董”，它天生为业务逻辑服务

很多新同事第一次看到4GL代码，第一反应是“这不就是老式Cobol吗”。这么说并不准确。4GL的全称是第四代语言，它和C、Java这种“通用型语言”最大的区别在于：它把数据库操作、屏幕输入输出、业务逻辑揉在了一起，用接近业务描述的方式让你直接操作数据。

在T100系统里，你很少需要手动处理内存指针、线程调度这些底层问题。你要做的核心事情就三件：

• 把画面上的字段拿来，做校验、做计算；
• 按条件查数据库，把结果显示出来；
• 把用户修改过的数据写回数据库。

所以4GL的思考方式更像是一套“面向表单和数据的脚本语言”。它不酷炫，但极其务实。你写一行SQL，就能查出一批数据；你定义一个画面控件，就能和变量绑定。这种直接感，是Java写CRUD时绕来绕去给不了的。

1.2 T100应用的基本开发层次

在T100里做一个功能，通常不是“写一个页面”那么简单，而是由几个层次配合完成的：

实际操作中，你拿到一个需求，不是马上坐下敲代码，而是先看表结构，再梳理数据流：数据从哪里来、经过什么转换、最后到哪里去。如果这一步没想清楚，后面写再多代码也是在打补丁。

1.3 入门学习的三个实用阶段

我不是科班出身，当年靠的就是“读、改、写”这三个阶段硬啃下来的：

1. 读代码阶段：不要一上来就自己造轮子。打开系统里已有的成熟程序，一行一行读，搞清楚每个函数、每个控制块在干什么。至少读二十个程序再动手。
2. 改代码阶段：找一个简单的小功能，比如“增加一个字段查询条件”“调整一个按钮的执行逻辑”，在别人的代码上做小改动。这能让你快速熟悉变量传递、SQL嵌入、画面绑定这些基本套路。
3. 独立写作业阶段：从一张临时表、一个查询画面开始，完整走一遍“建表→画面→查询→增删改→按钮事件”的流程。这是把知识变成能力最重要的一步，别指望跳过前两步直接到这一步。

2. 把最高频的语法吃透：字符串、数组与日期处理

2.1 字符串处理：基本功决定代码漂不漂亮

ERP开发里，字符串处理出现频率高得惊人：客户编号、物料编码、单据号、备注信息、界面标签……几乎每个画面都在跟字符串打交道。真正常见的问题是：

• 接收一个变量，不确定它是不是空；
• 需要把用户输入的多值用逗号拆开，变成数组去查询；
• 拼接一段动态SQL条件，结果漏了空格、多了一个引号。

我见过不少新同事写出的代码，光一个“判空”就有三种写法，而且每种都可能踩坑。比如直接判断某个字符串变量是否等于空值，结果字段里存的是三个空格，条件判断永远不成立。比较稳妥的做法是先把变量做一次标准化处理：

-- 伪代码骨架：统一去除首尾空白 LET ls_value = trim(ls_value) IF ls_value IS NULL OR ls_value = '' THEN -- 当作空值处理 END IF

在T100的4GL环境里，字符串函数的名字在不同小版本上略有差异，但核心思路不变：先把输入收干净，再进入业务判断。我自己的习惯是封装一个公共函数，专门负责“把任意输入变成安全的字符串”，要么返回有效值，要么返回空，绝不让空格和NULL在业务逻辑里到处游荡。

另一个高频需求是字符串拆分。比如画面上让用户输入多个单号，用逗号隔开，程序里需要把它拆成一个数组，逐个处理。这类代码不要每次现写，封装成工具函数，放到公共Include文件里，能省很多时间。

2.2 动态数组：告别固定长度

早期4GL代码里经常看到一堆固定长度的数组定义，比如一次性定义 100 个元素的数组。这种做法的问题是：数据一多就溢出，数据少了又浪费内存。现在开发一定要养成使用动态数组的习惯。

动态数组的处理逻辑是：先定义一个空数组，然后按照实际数据量往里追加或插入元素。比如从数据库查出一批货品编号，你不需要提前猜有多少行，只要循环往数组里加就行：

DEFINE la_item DYNAMIC ARRAY OF STRING DEFINE lv_item_no STRING DEFINE li_index INTEGER -- 假定从游标中逐行取得货品编号 WHILE 数据未取完 LET li_index = la_item.getLength() + 1 LET la_item[li_index] = lv_item_no END WHILE

动态数组在“批量处理”场景下特别有用。比如库存更新，你可以先把符合条件的单据头一次性查进数组，再逐行做明细处理，避免了反复查询数据库，性能和可读性都能提升一个档次。

2.3 日期与时间：ERP里绕不开的坑

日期时间是ERP业务里真正的重灾区。订单日期、出货日期、应收到期日、生产工单开完工日……每个业务都离不开日期，而日期在比较、存储、显示三个环节经常“打架”。

最典型的问题就是字符串形式的日期和真正的日期类型混淆。比如数据库字段是日期类型，你从画面拿到的是字符串“20240101”，直接拿它去和日期字段比较，很多环境会报格式错误或者比较结果不符合预期。

我的建议是，在程序边界处完成一次显式转换。画面、报表、中间文件传来的字符串都先转换成程序统一使用的日期类型，再进行业务处理；输出时再统一转回约定格式。这样逻辑内部始终只有一种日期形态，就不会出现“这个字段该传字符串还是该传日期”的混乱。

另外，做日期范围查询时，要特别注意边界值。比如查询某天的数据，正确条件通常应该是“大于等于当天零点 且 小于第二天零点”，而不是直接“等于当天”。否则当天有跨小时的数据时，结果往往会对不齐。

2.4 自建工具箱：把常用函数沉淀下来

做了几个项目之后，我强烈建议大家维护一个自己的工具箱文件。不用多复杂，把高频的逻辑收进去就行：

• 字符串安全转换、去空格、空值替换；
• 数组与逗号字符串互转；
• 日期格式合法校验、负数处理；
• 数据库返回码的通用判断；
• 日志写入的公共过程。

这些函数刚开始只有四五个，用着用着你就会发现，很多业务逻辑可以一层层复用。等积累到二十来个的时候，新写一个功能，大部分时间都花在“业务规则”上，而不是花在底层琐碎处理上，效率会有非常明显的变化。

3. 画面与交互：界面代码别写成一团乱麻

3.1 画面程序的逻辑分区

T100的画面程序，看起来比Web前端简单，但它同样需要在结构上做分区。我见过最痛苦的项目，是整个画面程序几千行，按钮事件、字段校验、数据库查询全揉在一起。这种程序，改一个字段联动，都像踩地雷。

我习惯把画面程序按职责分成几块：

• 初始化区：设置默认值、初始环境；
• 字段校验区：某个字段变化时触发，负责格式和依存关系校验；
• 动作事件区：按钮点击后要执行的动作；
• 刷新函数区：统一的画面重绘函数，避免到处写刷新逻辑。

这样分区之后，代码最大的好处是“好找”。出问题时，你知道应该去哪个区域排查，而不是从头拉到尾找焦点。

3.2 字段默认值、校验与联动

字段默认值什么时候赋值，是一个经常被忽略的小问题。如果你在画面每次刷新时重置默认值，用户填到一半的数据很容易被清掉；如果完全不做默认值，新功能录入时又会很麻烦。

我的经验是：默认值分两类处理。一类是画面打开时赋值的常量，比如单据状态“已暂存”、操作员编号等；另一类是业务相关联动值，比如根据客户编号带出客户名称、币种、付款条件。后者应该放在“客户编号变化”的事件里处理，而不是统一塞进初始化区。

多个字段联动时，有一个通用的顺序建议：先清空受影响的旧值，再执行数据查询，最后刷新画面。这样做的好处是，即使查询失败，画面上也不会残留上一次的错误数据误导操作员。

3.3 主表明细：数组驱动画面

T100里特别常见的画面结构就是“上方主表、下方明细”。主表是一条单据头，明细是很多条单据行。这种画面上，最容易出问题的不是数据展示，而是增删明细行之后的总量汇总和实时刷新。

我常用的模式是：明细数据全程放在动态数组里，画面只负责显示数组当前的内容。操作员新增一行，就往数组插一个元素；修改数量，就更新对应元素，然后重新计算汇总；删除明细，就删除数组元素。所有业务逻辑都作用在内存数组上，最后统一刷一遍画面。

这样做有个显著的好处：批量操作时，不会因为画面刷新频繁而产生卡顿；同时如果用户最后放弃保存，内存数组可以直接作废，不会对数据库产生任何影响。真正常见的问题是，一些同事直接在画面网格上改一格就触发查询和刷新，导致操作一多画面就“飘”，要尽量避免。

3.4 先确认、再做事：常用交互顺序

T100里的按钮动作，很多时候需要先让用户确认。比如“删除单据”“重开工单”“清空库存”，这类危险动作不能点一下就执行。

规范的做法是三步走：

1. 前端校验：先检查必填字段、数量是否合法；
2. 二次确认：弹出确认提示，明确告诉用户即将执行什么操作；
3. 正式执行：用户确认后，再开始数据库操作和画面刷新。

弹窗的具体写法在不同框架里不一样，但思想是通用的。我见过一些程序把弹窗写在数据库操作之后，结果数据已经改了用户才发现点错了，这种顺序问题一旦出现，往往要花很大力气去补救数据。

4. 数据库访问与事务处理：把数据搞干净，程序才不乱

4.1 一段标准查询的写法套路

T100这种ERP系统，本质上就是一个操作数据库的系统。SQL写得规不规范，直接决定程序后期好不好维护。我写查询时的套路是：

• 先用常量条件确认主表、关联表、筛选字段；
• 再把用户传入的查询条件逐个拼接进去；
• 最后统一排序，如果需要分段取数再控制取数范围。

动态条件拼接是查询里最容易出错的部分。毛病通常出在“第一个条件”和“后续条件”的拼接上，经常会多出一个WHERE或者多出一个AND。我自己的做法是维护一个条件数组，把每个条件片段都放进数组，最后统一用“AND”连接，避免手写字符串拼接出现语法错误。

4.2 游标与批量处理：循环里别反复开查询

4GL里用游标逐行处理数据是家常便饭。但很多性能问题都出在同一种写法上：外层循环一行数据，内层又打开一个游标查关联数据。数据量小的时候没感觉，数据量一到几千行，程序就明显变慢。

正确的思路是：能用一次查询取回来的数据，绝不用多次查询。比如先一次查回所有单据头到数组，再根据单据头数组批量取明细，或者用带关联的查询一次把主表明细都取出来。

游标处理还有个容易忽略的点：打开游标要用完就关闭，不要图省事一直开着。尤其是在循环里反复打开同一个游标，不仅消耗资源，还容易造成数据库锁等待。

4.3 事务边界：不是所有地方都要随手提交

在T100里，事务处理的核心原则是：短、明确、成对。一个事务从开始到提交，中间的数据库操作应该是一个完整的业务单元。比如“更新单据头+更新库存+写流水”，这三件事要么全成功，要么全回滚，中间不要出现一半成功一半失败的情况。

很多新同事容易犯的错是，在每个更新语句后面立即提交，结果业务执行到一半报错，前面的数据已经写进去了，造成一堆“脏数据”。反过来，也有同事全程不提交，直到程序结束才提交，如果程序异常退出，整个事务长时间占用数据库资源。

我的实践建议是：在开始一个不可分割业务前显式开启事务控制；业务逻辑全部成功后提交；任意一步失败就回滚。不要在循环体内部“随写随交”，除非你能明确证明这个步骤本身就是一个完整业务单元。

4.4 动态SQL与参数化：别只知道字符串拼接

动态SQL在T100里很常用，因为查询条件往往是运行时才能确定的。但动态SQL最忌讳的就是直接把用户输入拼成字符串执行。这既可能造成SQL语法错误，也可能带来安全隐患。

条件允许时，尽量使用参数化方式执行动态SQL：把条件值作为参数传入，而不是拼在SQL文本里。这样做的好处有两个：第一，防止特殊字符破坏查询语句；第二，避免数据量大时反复拼接导致性能问题。

在封装动态查询时，最好做一个统一的参数管理结构，把每个条件字段名、对应的变量、操作符集中维护。这样以后加一个查询条件，只需要往里加一条配置，而不是复制一大段代码。

5. 调试与避坑：几个最容易让人翻车的现场复盘

5.1 空字符串和“空白”不是一回事

有一次排查一个查询功能，用户明明输入了条件，程序却查不出数据。断点一看，画面传来的字段值变成了三个空格。原因是用户在输入框里不小心多打了空格，程序拿着带空格的字符串去数据库匹配，自然匹配不上。

这类问题特别隐蔽，因为你从画面上看不到前后空格。我的处理方案是，凡是用户输入的字段，进入业务逻辑之前一律先做去空格处理。不光是查询条件，包括保存时写入数据库的字段，也要做同样的清理。否则数据库里存了一堆带空格的客户编号，后面做关联查询的时候怎么都对不上。

5.2 日期格式：20240101和2024/01/01不是同一个东西

日期比较出问题，多半是因为格式不一致。数据库里存的是日期类型，画面上显示的是“2024/01/01”，动态SQL里你却拿“20240101”去比较，有些环境直接报错，有些环境则比较结果完全错误。

踩过几次坑之后，我现在只要涉及日期，就会先确认三种场景各自用的格式：

边界值问题同样要警醒。查询“某一天”的数据，除非数据库字段精确到了时分秒，否则用等号必然丢数据。正确做法还是左闭右开的天区间比较。

5.3 并发更新：明明查到了，更新却提示找不到记录

多用户同时操作时，偶尔会出现一种诡异情况：刚才查出来的数据，SELECT还正常，等到执行UPDATE时，系统却提示找不到记录，或者影响行数为0。这通常不是程序逻辑错了，而是数据在“查询”和“更新”之间被别人改了。

一个常见原因是：UPDATE语句的WHERE条件里没有带上主键或唯一键，而只是带了一堆普通条件。由于条件不唯一，可能匹配不到原来那条记录，或者同时匹配了多条。解决方法是，所有UPDATE和DELETE都必须以主键或唯一键作为定位条件，其他字段条件只能作为附加过滤，不能让它们成为定位依据。

5.4 生产环境没有调试器，怎么定位问题

在开发环境你可以用断点看变量，到了生产环境往往没有调试条件。这时候我的排错顺序是：先看现象、再查日志、然后抽SQL。

具体操作有几步：

1. 让用户提供能稳定复现的操作步骤和输入值；
2. 检查程序是否有关键步骤日志，如果没有，临时加日志输出到特定文件；
3. 把程序生成的SQL语句原样复制到数据库工具里执行，确认查询结果是否和预期一致；
4. 核对后台传入参数是否在程序入口就已经变形。

日志输出是个非常实在的技巧。有时候不需要完整日志框架，只要在关键函数里把输入参数、执行到哪一步、返回码是什么，一行一行写进日志文件，就足够定位大多数诡异问题。很多程序写完了之后再也不看，等出了问题才后悔当初怎么没多写几行日志。

6. 性能与可维护性：慢程序和高维护成本，多半是同一个原因

6.1 先从N+1查询讲起

N+1查询是T100程序变慢最常见的原因。什么叫N+1？就是程序先查了一次主表得到N条记录，然后在一个循环里，对每条记录再去查一次关联表，总共执行了“1+N”次数据库查询。当N是100、1000时，性能问题立刻就暴露出来了。

比如查一张订单列表，程序遍历订单头，每次循环去查一次客户主档。200笔订单就要查201次库。优化思路很简单：先一次把所有订单需要的客户编号取出来，再去客户主档一次性查出全部客户信息到数组，最后内存匹配。

在4GL里，能一次取回的绝不要循环去取。这一点是最能立竿见影的性能优化手段。

6.2 WHERE字段上的函数陷阱

还有一个经常被忽视的性能杀手：在WHERE条件里对字段做函数处理。比如要把销售日期按月份分组，程序写了个“取前6位”的字符串截断然后用它去比较。这种写法会让数据库无法走索引，导致全表扫描。

实际业务里，如果频繁按月份查询销售记录，更合理的做法是在表设计阶段就增加一个“月份”冗余字段，或者使用数据库原生的日期截断能力，而不是每次查询都对字段做自定义函数运算。

排查SQL性能时，我会优先把每个WHERE条件过一遍：是不是对字段做了计算？是不是类型不匹配导致隐式转换？过滤顺序能不能先缩小数据量再去关联？往往问题就在这些看起来不起眼的地方。

6.3 界面刷新与大数据量明细

明细数据非常多的时候（比如上千行的出入库记录），画面会很卡。其中一个原因是，每次修改一个单元格，程序就刷新整个画面，导致所有网格重新绘制。这里最常见的原因是，没有区分“局部刷新”和“整体刷新”。

我建议的做法是：按需重绘。单字段变化，只刷新受影响的区域或单元格；批量数据变化，才刷新整个明细网格。另外，大数据量明细不要一次性全部加载到画面，考虑分页加载或按滚动延迟加载，可以让画面流畅很多。

还有一个小小的点：明细画面的刷新函数里如果做了大量排序、汇总计算，尽量把这些计算放到数组层面完成，而不是靠画面重绘时逐行处理。

6.4 让下一任开发者少掉头发的小动作

维护性差的代码，往往不是技术水平问题，而是习惯问题。我总结过几点看似不起眼但极其有用的动作：

• 命名要能“见名知意”：变量名、函数名别用a、b、c，也别用拼音缩写，哪怕多写几个字符，后面省的时间远超这几个字符。
• 一个函数只做一件事：超过一百行的函数，如果能拆分尽量拆。功能单一时，测试、排查、复用都更容易。
• 删除死代码：被注释掉的、已经不再被调用的代码，该删就删，不要当“传家宝”留着。版本管理工具里有历史，真需要再找回也不难。
• 在关键业务点写注释：注释不要写“这里加了一个判断”，而要写“为什么加这个判断，解决了什么问题”。后者才真正有价值。

最后说一个不算技巧但很重要的体验。4GL+T100的开发，很多时候真正的瓶颈不是语言本身，而是你对业务表结构的理解深度。我见过不少新同事把大量时间花在调试SQL拼接上，却忽略了先想清楚这张表的数据流动逻辑：谁在写它、谁在读它、它和周边表的关系是什么。写代码之前先在草稿纸上把数据流画一遍，比学会任何一个API都管用。