4. CAPL核心语法：流程控制、函数与作用域
好，咱们进入CAPL的核心语法部分。说实话，很多刚接触CAPL的朋友，觉得它跟C语言长得像，就按C的套路写。结果呢？跑起来各种莫名其妙的问题。我当年也踩过这个坑。今天咱们就把流程控制、函数和作用域这三个硬骨头啃下来。
4.1 流程控制：if/else、while、for
流程控制，说白了就是让脚本知道「什么时候该干什么事」。CAPL里最常用的就是if/else、while和for。咱们一个一个说。
4.1.1 if/else 条件判断
这个最简单，也最容易出错。我见过太多人把条件写反了，或者漏了else分支。
// 基础用法
if (gSignalValue > 50)
{
write("信号值超过阈值，当前值：%d", gSignalValue);
}
else if (gSignalValue > 20)
{
write("信号值在安全范围内");
}
else
{
write("信号值偏低，请检查");
}注意：CAPL里没有「else if」这个关键字，它是「else」后面跟一个「if」语句。很多人写习惯了C语言的「else if」，在CAPL里直接写，编译能过，但逻辑可能不对。我建议你养成习惯，每个if都配上花括号，哪怕只有一行代码。
我在项目中遇到过一个问题：一个同事写了个if判断，条件里用了「==」比较浮点数。结果呢？因为浮点数精度问题，永远进不了那个分支。排查了一下午。所以，比较浮点数时，最好用范围判断，别用精确相等。
4.1.2 while 循环
while循环在CAPL里用得特别多，尤其是等待某个事件发生的时候。比如等待总线消息、等待信号变化。
// 等待信号值变为0
while (gSignalValue != 0)
{
TestWaitForTimeout(10); // 等待10ms
if (testStepCount > 100)
{
testStepFail("超时，信号未归零");
break;
}
}小技巧：while循环一定要有退出条件，否则就是死循环。我习惯在循环里加一个计数器，超过一定次数就强制退出，并报错。这样即使条件永远不满足，脚本也不会卡死。
你想想看，如果while循环里没有TestWaitForTimeout，CAPL会一直占用CPU，其他事件都处理不了。嗯，这里要注意，CAPL是事件驱动的，别用空转的while循环。
4.1.3 for 循环
for循环在遍历数组或执行固定次数的操作时很好用。CAPL的for循环跟C语言基本一样。
// 遍历数组
int arr[5] = {10, 20, 30, 40, 50};
int i;
for (i = 0; i < 5; i++)
{
write("arr[%d] = %d", i, arr[i]);
}
// 发送多条CAN消息
for (int j = 0; j < 10; j++)
{
message 0x100 msg;
msg.dlc = 8;
msg.byte(0) = j;
output(msg);
TestWaitForTimeout(100);
}核心要点：for循环里的变量，建议在循环外部声明。CAPL对变量的作用域管理比较严格，在for循环内部声明的变量，循环结束后可能就访问不到了。
4.2 函数定义与调用
函数是代码复用的基础。CAPL的函数定义跟C语言很像，但有一些自己的特点。
4.2.1 函数的定义
// 无返回值函数
void CheckSignalValue(int value)
{
if (value < 0 || value > 100)
{
write("信号值异常：%d", value);
}
}
// 有返回值函数
int CalculateChecksum(message *msg)
{
int sum = 0;
int i;
for (i = 0; i < msg.dlc; i++)
{
sum += msg.byte(i);
}
return sum % 256;
}我个人习惯把函数名写得尽量清晰，比如「CheckSignalValue」而不是「CSV」。这样半年后回头看代码，不用猜这个函数是干嘛的。
4.2.2 函数的调用
调用函数很简单，直接写函数名加参数就行。但要注意，CAPL里函数调用是同步的，也就是说，函数执行完才会返回。
// 调用示例
int result;
result = CalculateChecksum(&canMsg);
if (result != expectedChecksum)
{
CheckSignalValue(canMsg.byte(0));
write("校验和错误，期望：%d，实际：%d", expectedChecksum, result);
}避坑指南：我曾经在函数里调用了一个耗时很长的操作，比如等待100ms。结果整个脚本都卡住了，其他事件处理不了。后来我才意识到，CAPL是单线程的，函数里不能有长时间的阻塞操作。如果需要等待，用定时器或者on timer事件。
4.3 作用域规则
作用域，说白了就是变量在哪些地方能访问。CAPL的作用域规则比C语言严格一些，我刚开始用的时候也犯过迷糊。
4.3.1 全局变量
全局变量在文件开头声明，整个文件都能访问。但要注意，不同CAPL文件之间的全局变量是独立的，不能互相访问。
// 全局变量
int g_TestCounter = 0;
float g_SignalThreshold = 50.0;
on start
{
g_TestCounter = 0;
write("测试开始，计数器归零");
}
on message 0x100
{
g_TestCounter++;
write("收到消息，当前计数：%d", g_TestCounter);
}4.3.2 局部变量
局部变量在函数或事件处理函数内部声明，只在那个作用域内有效。
on message 0x200
{
int localCounter = 0; // 局部变量
localCounter++;
write("局部计数：%d", localCounter);
// 这里可以访问全局变量 g_TestCounter
write("全局计数：%d", g_TestCounter);
}
// 在另一个事件里，localCounter 就不存在了
on message 0x300
{
// localCounter 在这里不可用
// 但 g_TestCounter 仍然可用
}建议：我一般把全局变量控制在5个以内，超过这个数，代码就容易乱。能用局部变量解决的问题，就别用全局的。你想想看，全局变量多了，调试的时候都不知道是谁改的。
4.3.3 静态变量
CAPL支持静态变量，用static关键字声明。静态变量在函数调用之间保持值不变，但只在声明它的文件内可见。
void CountMessages()
{
static int callCount = 0; // 静态变量，只初始化一次
callCount++;
write("CountMessages 被调用了 %d 次", callCount);
}
on message 0x400
{
CountMessages(); // 每次调用，callCount 都会增加
}我记得有一次写自动化测试脚本，需要统计某个信号出现的次数。用静态变量就特别方便，不用全局变量，也不用担心被其他地方意外修改。
4.4 实战经验总结
说了这么多，我总结几条实战经验，希望对你有帮助：
- 流程控制要简洁：if/else嵌套不要超过3层，超过就考虑用函数拆分。
- 函数要单一职责：一个函数只做一件事，比如「检查信号值」和「计算校验和」分开写。
- 变量作用域要小：能用局部变量就别用全局，能用静态变量就别用全局。
- 循环要有退出机制：while循环一定要有超时退出，防止死循环。
最后说一句：CAPL的语法虽然简单，但用好它需要经验和思考。我刚开始写CAPL脚本时，也经常写出bug。但只要你理解了流程控制、函数和作用域这三个核心概念，大部分问题都能迎刃而解。嗯，今天就到这里，下一章咱们聊聊CAPL里的事件处理，那才是自动化测试的精髓。