企业官网建设流程全解析

4.2 现象：test.sh显示FAILED，但手动./weird < 1.in输出与1.out完全一致

原因：test.sh使用diff -wB比较，而你的编辑器（如 VS Code）可能在保存时添加了 BOM（字节顺序标记）或 UTF-8 with BOM 编码，导致1.out文件开头有不可见字符。
解决：

# 检查 1.out 是否有 BOM hexdump -C tests/weird-algorithm/1.out | head -3 # 若输出含 `ef bb bf`，则存在 BOM # 用 iconv 去除 BOM（Linux/macOS） iconv -f UTF-8 -t UTF-8//IGNORE tests/weird-algorithm/1.out | sed 's/^\xEF\xBB\xBF//' > tmp && mv tmp tests/weird-algorithm/1.out # 或直接用 dos2unix（需安装） dos2unix tests/weird-algorithm/1.out

4.3 现象：程序在本地./weird < 1.in正常，但test.sh报Segmentation fault

原因：test.sh会多次调用你的程序（每组测试一次），而你的代码存在全局变量未初始化、数组越界或递归过深。尤其tree-algorithms/题目中，DFS 递归深度可能达 $ 2\times10^5 $，超出默认栈大小。
解决：

// 在 main() 开头添加栈扩容（仅 Linux） #include <sys/resource.h> int main() { const rlim_t kStackSize = 64 * 1024 * 1024; // min stack size = 64 MB struct rlimit rl; int result; result = getrlimit(RLIMIT_STACK, &rl); if (result == 0) { if (rl.rlim_cur < kStackSize) { rl.rlim_cur = kStackSize; setrlimit(RLIMIT_STACK, &rl); } } // ... your code }

4.4 现象：test.sh报Time limit exceeded，但time ./weird < 1.in显示0.00s

原因：test.sh对每组测试单独计时，且使用ulimit -t 1限制 CPU 时间为 1 秒；而time命令测量的是 wall clock time（含 I/O 等待）。你的程序可能在cin读取大输入时阻塞，或cout缓冲未刷新。
解决：

#include <iostream> using namespace std; int main() { ios::sync_with_stdio(false); // 关闭 stdio 同步 cin.tie(nullptr); // 解绑 cin/cout // ... your code }

4.5 现象：test.sh报Wrong answer on test 5，但diff显示仅末尾多一个空行

原因：C++ 中cout << endl会刷新缓冲区并输出\n，但若程序提前return 0，部分缓冲区内容可能未写出。更隐蔽的是，vector或string析构时可能触发隐式输出。
解决：

#include <iostream> #include <vector> using namespace std; int main() { // ... your logic for (size_t i = 0; i < seq.size(); ++i) { cout << seq[i]; if (i < seq.size() - 1) cout << " "; } cout << '\n'; // 用 '\n' 替代 endl，避免刷新 cout.flush(); // 强制刷新缓冲区 return 0; }

5. 自动化评测与持续集成：用 Makefile + GitHub Actions 构建个人算法流水线

刷题不是终点，把 CSES 当作你的「算法模块单元测试集」才是高阶用法。我坚持用 Makefile 管理所有题目，配合 GitHub Actions 实现每次git push后自动编译、测试、生成覆盖率报告。这套流程让我在 3 个月内稳定提交 200+ 题，且 0 WA（因本地测试即 CI 测试）。以下是可直接复用的最小可行方案。

5.1 用 Makefile 统一管理编译与测试

在仓库根目录创建Makefile，定义通用规则。关键点：每个题目目录对应一个Makefile规则，支持增量编译、一键测试、失败中断：

# Makefile SHELL := /bin/bash CXX := g++ CXXFLAGS := -std=c++17 -O2 -Wall -Wextra # 自动发现所有题目目录（排除 README.md 等） PROBLEMS := $(shell find problems/ -mindepth 1 -maxdepth 1 -type d -not -name ".*" | sed 's/problems\///' | sort) .PHONY: all $(PROBLEMS) clean all: $(PROBLEMS) # 为每个题目生成规则：make weird-algorithm $(PROBLEMS): @echo "=== Testing $@ ===" @cd problems/$@ && \ $(CXX) $(CXXFLAGS) ../../$@.cpp -o ../../$@ && \ chmod +x ../../$@ && \ ../../test.sh ../../$@ || { echo "FAIL: $@"; exit 1; } clean: rm -f $(PROBLEMS) *.o find problems/ -name "*.out" -delete # 示例：只测试前 3 题 first3: $(wordlist 1,3,$(PROBLEMS))

逻辑说明：$(PROBLEMS)动态获取所有题目名（如weird-algorithm）；$(CXX) ... -o ../../$@将可执行文件放在根目录，避免路径混乱；|| { echo "FAIL"; exit 1; }确保任一题失败即中断，符合 CI 场景。

使用方式：

# 编译并测试所有题（耗时长，慎用） make # 只测试 weird-algorithm 和 missing-number make weird-algorithm missing-number # 清理所有二进制 make clean

5.2 GitHub Actions 自动化：每次 push 触发全量回归测试

在.github/workflows/cses.yml中定义 workflow。重点：复用本地test.sh，不引入新依赖，失败时精确定位到题号：

name: CSES Regression Test on: [push, pull_request] jobs: test: runs-on: ubuntu-22.04 steps: - uses: actions/checkout@v4 - name: Install dependencies run: | sudo apt-get update sudo apt-get install -y g++ make - name: Compile and test all problems run: | # 设置超时防止挂起 timeout 30m make -j4 || { echo "Test failed"; exit 1; } env: # 避免交互式提示 DEBIAN_FRONTEND: noninteractive

参数说明：timeout 30m防止某题死循环拖垮 CI；make -j4并行编译加速；DEBIAN_FRONTEND: noninteractive避免 apt 安装时弹出配置对话框。CI 日志会清晰显示=== Testing tree-diameter ===及其结果，失败时直接跳转到对应题目的 GitHub 目录。

5.3 进阶技巧：用gcov生成算法题覆盖率报告

CSES 题目本质是黑盒测试，但你能知道自己的代码哪一行没被执行过。以weird-algorithm为例，添加覆盖率采集：

# 编译时加入 gcov 标志 g++ -std=c++17 -O0 -fprofile-arcs -ftest-coverage weird.cpp -o weird # 运行所有测试（生成 .gcda 文件） cd problems/weird-algorithm/ for f in ../../tests/weird-algorithm/*.in; do base=$(basename "$f" .in) ../../weird < "$f" > /tmp/out diff -wB "$f".out /tmp/out done # 生成覆盖率报告 gcovr -r . --html --html-details -o coverage.html

打开coverage.html，你会看到weird.cpp每行的执行次数。如果while (n != 1)循环体从未执行（n=1时直接退出），说明你漏测了边界情况——这正是 CSES 设计的精妙之处：它逼你思考所有输入分支，而非仅满足样例。

我坚持每天用make跑一遍当天做的题，周末用make clean && make全量回归。三年下来，我的 CSES 提交记录里没有一次 WA 是因为逻辑错误，全是 I/O 或环境问题——而这些问题，在本地 Makefile 和 CI 里已被拦截。这种确定性，比刷题数量重要十倍。希望帮到你。

本文还有配套的精品资源，点击获取