算法刷题避坑指南：从数据规模到易错点的实战总结

在LeetCode刷题或参加ACM/蓝桥杯等算法竞赛时，我们常常会遇到这样的情况：思路明明是对的，但提交后总是报"运行超时（TLE）"、"答案错误（WA）"或者"段错误（RE）"。

很多时候，问题并不出在核心算法逻辑上，而是忽略了数据规模、边界条件和语言特性。今天，我就结合实战经验，为大家总结一份算法题的"避坑指南"，希望能帮大家少走弯路，提高AC率！

在写代码之前，先瞄一眼题目给出的数据范围（通常用 NN 表示），这能直接决定你应该使用哪种算法。一般的在线判题系统（OJ）在1秒内大约能执行 107107 到 108108 次基本运算。

根据这个基准，我们可以总结出以下"反推算法"的经验法则：

避坑提示：

如果题目给出 N=105N=105 ，千万不要尝试写 O(N2)O(N2) 的双重循环暴力解法，否则大概率会超时！此时应优先考虑 O(Nlog⁡N)O(NlogN) 的排序或 O(N)O(N) 的线性扫描。

C++中的 int 类型通常占用4个字节，其取值范围大约是 −2×109−2×109 到 2×1092×109 。

全局定义（推荐）： 在主函数外部定义的数组会自动初始化为0，且能申请的空间较大（通常在百兆级别）。
局部定义： 在 main 函数内部定义的数组不会自动初始化（是随机值），且栈空间有限。如果开一个 int a[10000][10000] 这样的大数组，极易导致**栈溢出（Stack Overflow）**引发段错误。

解决方案： 在 main 函数开头加上：

复制代码

ios::sync_with_stdio(false);
cin.tie(0);

或者直接回归原始的 scanf 和 printf。

正确写法： sort(a + 1, a + n + 1); // 左闭右开原则

vector 越界： 如果 vector 没有预先 resize 或 push_back，直接用下标 a[10] 访问会直接段错误。
set 的查找： 使用 se.lower_bound(sum) 是 O(log⁡N)O(logN) ，但如果写成 lower_bound(se.begin(), se.end(), sum)，由于迭代器不支持随机访问，会退化成 O(N)O(N) 的线性查找，导致超时！
map 的自动插入： C++的 map[key] 如果访问了不存在的键，会自动插入一个默认值（int为0）。如果只是想判断是否存在，建议使用 map.count(key) 或 map.find(key)。

错误示范： a <= b ? c : d + 1 （可能先算后面的加法）
正确习惯： 遇到不确定的地方，多加括号 ！例如：a <= (b ? c : d)。

不要忽视特判（边界条件）

题目说 NN 个点，一定要考虑 N=1N=1 的情况；题目说非空数组，也要想一下如果是空数组怎么办。很多时候WA就是因为死在了 N=0N=0 或 N=1N=1 这种极端边界上。
先暴力，再优化

如果一时想不出最优解，先写一个暴力解法（DFS或暴力枚举）。这不仅能帮你验证对题目的理解，还能用来对拍（生成小数据对比输出），是调试复杂算法的神器。
变量命名与覆盖

在嵌套循环或复杂逻辑中，注意不要重复使用 i, j, k 等变量名，防止局部变量覆盖全局变量，导致逻辑混乱。
看清输出格式

题目要求"从小到大输出"还是"按字典序输出"？样例输出中数字之间是空格还是逗号？这些细节往往决定了最后的成败。

算法能力的提升不仅在于刷了多少道题，更在于是否养成了严谨的编码习惯。希望这篇总结能帮你避开那些"隐形"的坑，祝大家刷题顺利，场场AC！