LeetCode把这道Hard题藏了3年，解法比题目本身更魔幻

LeetCode第3385号题「Equal Sum Grid Partition II」上线两周，通过率不到15%。一个矩阵切割问题，硬是把十年老程序员逼到翻线性代数课本。

01 题目到底在考什么

给你一个m×n的整数矩阵，要求切一刀——横切或竖切——让两边元素和相等。能切就返回true，不能就false。

听起来像小学奥数？LeetCode给它标了Hard。因为约束条件藏着杀机：矩阵最大到500×500，元素和可能爆掉64位整数。

作者@rakhmedovrs在题解里写得很直白：「我当年做矩阵研究，看到这道题以为能十分钟搞定，结果花了四十分钟。」

核心陷阱在于切割方向的组合爆炸。横切有(m-1)种位置，竖切有(n-1)种，暴力枚举是O(mn(m+n))，在500×500规模下直接超时。

02 一个转置操作省掉一半代码

这位前学术研究员的解法很有意思。他选择只实现横切判断，竖切怎么办？把矩阵转置（transpose），再调用同一套横切逻辑。

转置的本质是沿主对角线翻转，行变列、列变行。用线性代数的说法，若原矩阵为A，转置后得到Aᵀ，那么对Aᵀ的横切等价于对A的竖切。

这招的妙处在于代码复用。横切逻辑写一遍，竖切逻辑零行代码——靠转置矩阵白嫖。

具体实现上，先算整个矩阵的总和total。如果total是奇数，直接返回false，因为无法分成两个相等的整数和。如果total是偶数，目标就是找一条切割线，让一边的和等于total/2。

横切时逐行累加前缀和，竖切时转置后同样处理。时间复杂度压到O(mn)，空间复杂度O(1)——除了转置需要的额外矩阵。

03 为什么这题通过率这么低

看讨论区的高频翻车点很有意思。很多人卡在整数溢出：题目没说元素范围，实际测试用例里和可能超过2³¹-1。用int累加前缀和，半路就崩了。

另一个暗坑是转置本身的开销。500×500的矩阵转置，内存分配和元素搬运不是免费午餐。有人在面试场景下拒绝转置，硬写两套逻辑，代码量翻倍，bug率也翻倍。

@rakhmedovrs的题解底下有条评论很扎心：「我写了80行处理两种切割方向，看到转置方案后默默删了50行。」

这题的Hard标签，一半给算法设计，一半给工程细节。边界条件、数据类型、代码简洁性，哪个没考虑到都过不了。

04 从一道题看LeetCode的出题趋势

「Equal Sum Grid Partition II」是系列第二题。第一题「Equal Sum Grid Partition」约束更宽松，允许切多刀，用动态规划就能解。

第二题改成只能切一刀，难度跳了不止一级。这符合LeetCode近年的出题风格：把经典问题加个限制条件，考察你能不能识别出本质变化。

矩阵类题目在面试中不算高频，但一旦出现就是区分度利器。因为大多数人日常写业务代码，很少手写二维数组操作，手生了就容易慌。

这位作者提到自己「years ago」做学术时天天跟矩阵打交道，才能快速定位到转置这个切入点。经验迁移的价值，在这道题上体现得很具体。

05 解法代码的关键细节

题解给出的Python实现里，有个容易被忽略的点：转置是用zip(*grid)配合list(map(list, ...))完成的，这在Python里比numpy.T更省内存，因为LeetCode的运行环境不一定加载了NumPy。

横切判断的核心循环长这样——逐行累加row_sum，检查是否等于target（即total//2）。找到就返回True，遍历完还没找到就返回False。

竖切直接return can_split(list(map(list, zip(*grid))))，递归调用自身。代码结构干净得像数学证明。

评论区有人追问：如果矩阵是1×n或者m×1怎么办？转置后维度交换，横切逻辑依然成立，不需要额外处理。这就是通用解法的威力。

这题目前只有不到200条题解，热度远低于同难度的图论或动态规划题。但它在考察维度上很完整：算法思维、代码工程、数学基础，三者缺一不可。

你在面试中遇到过矩阵类题目吗？是当场写出优雅解法，还是事后才拍大腿？