多维数组值莫名改变原因排查：最长公共子序列程序异常

嘿，这个诡异的问题我太熟了！在写最长公共子序列（LCS）这类动态规划代码时，这种“明明没赋值，数组值却自己变了”的情况，90%以上都是内存越界访问搞的鬼，尤其是多维数组的内存布局很容易踩坑。结合你说的场景——外部循环首次迭代、j=0且k=5时arr[2][0]变成1，我给你拆解下可能的原因和排查方向：

最可能的元凶：越界写入覆盖内存 #

C/C++里的多维数组是按行优先顺序连续存在内存里的。比如你定义了int arr[m][n];，那么arr[i][k]的下一个内存位置就是arr[i][k+1]，一旦k+1超过第二维的最大下标（n-1），写操作就会直接跳到下一行的第一个元素arr[i+1][0]。

举个具体例子：假设你的两个字符串长度分别是2和5，所以DP数组定义成int arr[3][6];（LCS通常要多一行一列存全0的边界条件）。当k=5的时候，如果你的代码不小心访问了arr[1][5]（第二维最大下标应该是4），这个写操作就会直接覆盖arr[2][0]的内存，导致它的值莫名变成1。

其他可能的诱因 #

• 初始化不彻底：你说第一行和第一列初始化为0，但有没有可能循环初始化时边界写错了？比如把for(i=0; i<=str1_len; i++)写成了i<str1_len，导致arr[2][0]根本没被初始化，本来就是垃圾值，后来被越界操作改成了1？
• 下标变量混淆：有没有可能在循环里把j、k这些下标变量搞混了？比如本来要操作arr[i][j]，结果写成了arr[k][i]，刚好在k=5的时候命中了arr[2][0]？
• 动态内存分配错误：如果是用malloc动态创建的二维数组，有没有可能计算内存大小时出错，导致数组实际分配的空间不够，后续写操作直接越界？

快速排查步骤 #

1. 确认数组定义：检查DP数组的维度是不是字符串1长度+1 × 字符串2长度+1，LCS的DP表必须多一行一列存全0的边界。
2. 加调试输出：在k=5的那个循环分支里，打印当前的i、j、k值，以及你正在访问的数组下标，看看是不是出现了k >= 第二维长度的情况。
3. 检查循环边界：所有涉及数组下标的循环，确认条件是< 长度而不是<= 长度（因为下标从0开始）。
4. 开编译器警告：开启编译器的越界检测警告（比如GCC的-Wall -Wextra），很多越界问题编译器会直接提示你。

内容的提问来源于stack exchange，提问作者I Like