写好程序后，第一件事一定是编译执行。程序通过编译可以检查一定的拼写错误。通过编译后，就是输入题目的测试用例，检查运行结果。注意，通过测试用例不代表程序正确。在提交之前，请尝试自行构造简单的样例继续测试，重点检查边界情况（是否有数组越界、程序没有考虑数据输入 0 的情况等）。有较充分把握后再提交为宜。

    比较糟糕的情况是，程序出了问题，而你对此毫无头绪。这时候就需要查错 debug，这也是一项基本功。然而越是熟练的选手往往较少出现代码层面的问题，即使有也能很快自查；越是初学者越会在意想不到的地方跌跟头。对此，你需要在不断练习中发现自己的失误之处，积累经验。

    有时，你对着标准程序写出了自己的程序，看起来明明是一样的，但你的程序却不能通过。你是否会急切地把自己 DIY 的部分都改成标准程序的样子？有一条个人经验——「错误不在你看见了的地方，而在你没看见的地方」。OJ 绝不会随随便便把你的程序判错，你一定是漏看了标准程序中的细节，而不是错在使用了不一样的方式。

    常见的不易察觉的失误：

    1. 运行时段错误：数组越界访问，或许是数组开小了
    2. 答案错误：检查程序的 == 是否写成= ，是否输出了多余调试信息，使用了未初始化的变量，回答多重询问时没有重置 vis 数组等，以及是否开了 long long

    在调试程序时，最暴力、最可靠的方式就是在程序中到处添加输出语句，打印中间结果，人工排查错误所在。当然，别忘了提交前把这些都注释掉。编译器的 debug 模式也可以进行调试工作，但对于 STL 容器的查看并不直观。

    面对人工难以判断答案正确性的情况，可以在解题程序的基础上，再写一个简单的暴力枚举解法版本，它可以运行缓慢，但要保证正确性。这样一来，你可以自己构造数据，在本地验证两个程序的输出是否一致。这种方法被称为「对拍」，是竞赛中的高级技巧。功能强大的对拍往往实现也比较复杂，读者如有需求可自行调查了解。