UART读取异常排查：未使用字符数组大小影响读取结果

这绝对是栈内存溢出/越界访问搞的鬼！虽然你觉得这些数组没被用到，但它们的大小直接改变了栈的布局，刚好把之前隐藏的越界问题的影响给暴露/掩盖了——咱们一步步拆解：

• 局部变量的栈存储逻辑：你声明的这些数组都是局部变量，默认存在程序的栈空间里。栈是从高地址往低地址“生长”的，变量会按声明顺序（或编译器优化后的顺序）依次排布在栈上。当你用小尺寸数组时，它们占用的栈空间很小，可能和UART接收缓冲区、或者存储UART读取结果的变量挨得非常近。
• 隐藏的越界写操作：你的代码里大概率存在某个地方（比如之前的UART数据处理逻辑）有越界写入的问题——比如用strcpy往某个小缓冲区写数据时没考虑字符串终止符'\0'，或者读取UART数据时没限制长度，导致写超了缓冲区的大小。这时候溢出的数据就会覆盖相邻的栈内存，刚好把UART相关的关键变量（比如接收计数、缓冲区指针）给改乱了，自然就出现乱码。
• 数组改大后的“避险”效果：当你把所有数组都改成10字节后，这些数组占用的栈空间变大了，相当于在越界写的位置和UART变量之间加了一层“缓冲”，溢出的数据只会覆盖这些数组的内存（而你又没用到它们，所以看不出异常），不会再碰UART相关的变量，因此读取就恢复正常了。但这只是临时规避，根本的越界问题还没解决！

• 检查所有UART相关的字符串/缓冲区操作：把不安全的strcpy、sprintf换成带长度限制的版本（比如strncpy、snprintf），并且手动添加字符串终止符（比如buff[sizeof(buff)-1] = '\0';），确保永远不会写超缓冲区大小。
• 用调试工具看栈布局：比如用GDB查看局部变量的内存地址，对比小数组和数组改大后，UART相关变量的位置变化，确认是不是被溢出覆盖了。
• 开启编译器的安全检查：比如GCC可以加-Wall -Wextra -Woverflow参数，让编译器帮你找出可能的越界风险；如果是桌面程序，还可以用-fsanitize=address开启地址 sanitizer，直接定位越界的代码行。

内容的提问来源于stack exchange，提问作者XxX_Code.Destroyer_XxX