1. 字符串与数字互转：一个被严重低估的基础设施层
做C/C++开发的人，几乎每天都在和字符串与数字之间的转换打交道。配置文件解析、命令行参数处理、网络协议报文解析、日志格式化输出、CSV导入导出——这些场景背后都站着一组看似平平无奇、实则暗藏杀机的函数：atoi、strtol、stoi、atol、strtoll、strtoul、strtoull、atof、strtof、strtod、sscanf、sprintf、snprintf、strtok。
很多人对它们的认知停留在"会用就行"的层面：atoi把字符串转成整数，sprintf把数据格式化成字符串，strtok按分隔符切分字符串。但真正在生产环境里踩过坑的人都知道，这组函数的边界条件、错误处理、平台差异、安全性问题，足以让一个看似简单的转换逻辑变成线上事故的导火索。
这篇文章不打算写成一份API手册——那种东西查文档就够了。我想做的是把这组函数放在真实的工程场景里，讲清楚它们各自适合什么场景、不适合什么场景、为什么会有这么多看起来功能重叠的变体、以及在实际项目中如何做出正确的选型决策。无论你是刚接触C/C++的新手，还是写了多年代码但一直"凭感觉"选函数的老手，相信都能从中找到一些之前没注意到的细节。
整篇内容会围绕几个核心问题展开：为什么atoi被广泛认为"不安全"？strtol系列的错误检测机制到底怎么用？C++的stoi和C的strtol在异常处理上有什么本质区别？snprintf相比sprintf解决了什么问题？strtok为什么不是线程安全的？这些问题的答案，直接决定了你写出来的代码是"能跑"还是"可靠"。
2. 从atoi到strtoull：整数转换函数的家族谱系与选型逻辑
2.1 atoi的原罪：无法区分"0"和"转换失败"
atoi的函数签名是int atoi(const char *str)，用起来极其简单——传一个字符串进去，返回一个整数。简单到让人忘记它有一个致命缺陷：当转换失败时，它返回0，而你无法判断这个0是字符串本身就是"0"，还是因为输入非法导致的。
int a = atoi("0"); // a = 0，合法转换 int b = atoi("abc"); // b = 0，转换失败 int c = atoi(""); // c = 0，空字符串这三种情况返回值完全一样。如果你的业务逻辑依赖"转换失败就报错"，atoi根本做不到。更糟糕的是，当输入的数字超出int范围时，atoi的行为是未定义的——注意，不是返回一个截断值，而是标准明确规定的"undefined behavior"。在某些平台上它可能返回INT_MAX，在另一些平台上可能返回一个完全无关的值，甚至可能触发异常。
这就是为什么在严肃的工程代码中，atoi几乎不应该出现在任何需要错误处理的场景里。它唯一的合理用途是：你百分之百确定输入是合法的、范围可控的数字字符串，且不需要区分失败情况。比如解析一个内部生成的、格式严格受控的配置值。
atol和atof的问题与atoi完全一样，只是目标类型不同。atol返回long，atof返回double，但它们同样无法报告错误，同样在溢出时行为未定义。
2.2 strtol系列：用endptr和errno构建完整的错误检测链
strtol家族是C标准库给出的"正确答案"。以strtol为例，它的签名是：
long int strtol(const char *nptr, char **endptr, int base);相比atoi，它多了两个关键参数：endptr和base。这两个参数正是错误检测的核心。
endptr是一个指向字符指针的指针。函数转换完成后，会让*endptr指向字符串中第一个未被转换的字符。如果整个字符串都是合法数字，*endptr会指向字符串末尾的\0；如果遇到非法字符，*endptr会指向那个非法字符的位置；如果根本没有数字可转换，*endptr会等于传入的nptr。
#include <stdlib.h> #include <errno.h> #include <limits.h> int parse_long(const char *str, long *out) { char *endptr; errno = 0; long val = strtol(str, &endptr, 10); if (endptr == str) { return -1; // 没有转换任何数字 } if (*endptr != '\0') { return -2; // 有尾部垃圾字符 } if (errno == ERANGE) { return -3; // 溢出 } *out = val; return 0; }这段代码展示了strtol的完整错误检测流程。注意几个细节：调用前必须手动将errno置为0，因为errno不会被函数自动清零；溢出检测依赖errno == ERANGE，而不是检查返回值是否等于LONG_MAX（因为LONG_MAX本身也可能是合法输入）；endptr的判断顺序应该是先判断是否等于str（完全无数字），再判断是否指向\0（有尾部垃圾）。
base参数支持2到36之间的任意进制，传0表示自动检测（0x前缀识别为十六进制，0前缀识别为八进制，否则十进制）。这个特性在解析配置文件时非常实用，比如解析颜色值0xFF0000或者权限掩码0755。
strtoll、strtoul、strtoull的用法与strtol完全一致，只是目标类型不同。strtoul和strtoull有一个额外的坑：它们会把负数输入转换为对应的无符号值。比如strtoul("-1", NULL, 10)返回ULONG_MAX，而不是报错。如果你的业务逻辑不接受负数，需要额外检查字符串是否以-开头。
2.3 C++的stoi：异常机制下的便利与代价
C++11引入了std::stoi、std::stol、std::stoll等函数，它们封装了strtol系列，但用异常代替了errno和endptr。
#include <string> #include <stdexcept> try { int val = std::stoi("123abc"); // val = 123，不抛异常 int val2 = std::stoi("abc"); // 抛出 std::invalid_argument int val3 = std::stoi("99999999999999"); // 抛出 std::out_of_range } catch (const std::invalid_argument& e) { // 处理非法输入 } catch (const std::out_of_range& e) { // 处理溢出 }stoi的便利之处在于：不需要手动管理errno，不需要检查endptr，异常机制让错误处理更符合C++的惯用法。但它也有几个需要注意的点。
第一，stoi同样允许尾部垃圾字符。std::stoi("123abc")返回123，不会报错。如果你需要严格校验整个字符串，仍然需要配合std::stoi的第二个参数pos来检查转换结束位置。
第二，异常的抛出和捕获有性能开销。在高频调用的热路径上（比如每秒解析数百万条报文），异常机制可能成为性能瓶颈。这种情况下，strtol或者C++17的std::from_chars是更好的选择。
第三，stoi的异常类型是std::invalid_argument和std::out_of_range，需要确保你的异常处理逻辑覆盖了这两种情况。很多人在写代码时只catch了std::exception，虽然能捕获，但丢失了具体的错误信息。
2.4 选型决策表：什么场景用什么函数
| 场景 | 推荐函数 | 理由 |
|---|---|---|
| 快速原型、输入绝对可信 | atoi/atol | 代码最简，无需错误处理 |
| 需要完整错误检测的C代码 | strtol/strtoll | endptr + errno 提供完整信息 |
| 需要解析不同进制 | strtol系列 | base参数支持2-36进制 |
| C++代码、异常可接受 | stoi/stol/stoll | 异常机制更符合C++风格 |
| 高性能热路径 | std::from_chars(C++17) | 无异常、无内存分配、最快 |
| 无符号数解析 | strtoul/strtoull | 注意负数转换问题 |
| 浮点数解析 | strtod/strtof | 精度和错误检测兼顾 |
注意：
std::from_chars虽然性能最优，但它不处理前导空白、不识别0x前缀（除非指定base为16），也不依赖locale。如果你的输入格式比较"脏"，strtol系列反而更省心。
3. 浮点数转换：strtod、strtof与atof的精度陷阱
3.1 atof的不可靠性与strtod的替代方案
atof的问题和atoi一模一样：无法报告错误，溢出时行为未定义。但浮点数的转换比整数更复杂，因为涉及到精度损失、舍入模式、特殊值（inf、nan）等问题。
strtod是浮点数转换的正确选择：
#include <stdlib.h> #include <errno.h> #include <math.h> int parse_double(const char *str, double *out) { char *endptr; errno = 0; double val = strtod(str, &endptr); if (endptr == str) { return -1; // 无数字 } if (*endptr != '\0') { return -2; // 尾部垃圾 } if (errno == ERANGE) { // 可能是溢出（返回HUGE_VAL）或下溢（返回接近0的值） if (val == HUGE_VAL || val == -HUGE_VAL) { return -3; // 上溢 } // 下溢通常可以接受，视业务需求而定 } *out = val; return 0; }strtod能识别inf、infinity、nan等特殊值（大小写不敏感），也能解析十六进制浮点数（如0x1.8p3）。这些特性在解析科学计算数据时很有用，但在解析用户输入时可能带来安全隐患——你未必希望用户输入nan导致后续计算出问题。
strtof是strtod的float版本，strtold是long double版本。它们的错误检测机制完全一致。
3.2 浮点数转换的精度问题：为什么0.1 + 0.2 != 0.3
这个问题虽然老生常谈，但在字符串转换场景下尤其值得注意。当你用strtod("0.1")解析时，得到的并不是精确的0.1，而是最接近0.1的可表示浮点数。这个值大约是0.1000000000000000055511151231257827021181583404541015625。
double d = strtod("0.1", NULL); printf("%.20f\n", d); // 输出：0.10000000000000000555这意味着，如果你用strtod解析用户输入的金额，然后进行累加计算，最终结果可能与预期有微小偏差。在金融场景下，这种偏差是不可接受的。解决方案是：金额用整数（分）存储和计算，只在显示时转换为浮点数；或者使用十进制浮点库。
另一个常见的坑是strtod的舍入模式。默认情况下，strtod使用"就近舍入"（round to nearest），但C标准允许实现选择其他舍入模式。在跨平台项目中，如果对精度有严格要求，需要确认目标平台的舍入行为。
3.3 sscanf的浮点数解析：便利与隐患并存
sscanf可以用%f、%lf、%Lf来解析浮点数：
double d; int n = sscanf("3.14abc", "%lf", &d); // n = 1, d = 3.14sscanf的返回值是成功匹配并赋值的项数。如果返回0，表示没有成功解析任何项；如果返回EOF，表示在第一次转换前就遇到了输入结束。
但sscanf在浮点数解析上有一个严重问题：它不报告溢出。如果输入的数字超出了double的范围，sscanf的行为是未定义的。此外，sscanf的格式字符串如果与输入不匹配，可能导致缓冲区溢出或其他安全问题。
在实际项目中，我倾向于用strtod替代sscanf做浮点数解析，因为strtod的错误检测更完整，性能也更好（sscanf需要解析格式字符串，开销更大）。
4. 格式化输出：sprintf、snprintf与缓冲区安全的攻防战
4.1 sprintf的缓冲区溢出：经典但致命的漏洞
sprintf的函数签名是int sprintf(char *str, const char *format, ...)，它把格式化后的字符串写入str指向的缓冲区，并返回写入的字符数（不包括结尾的\0）。
问题在于：sprintf不知道缓冲区有多大。如果格式化后的字符串超出了缓冲区容量，就会发生缓冲区溢出——覆盖相邻内存，可能导致程序崩溃、数据损坏，甚至被利用来执行恶意代码。
char buf[10]; sprintf(buf, "%s", "this is a very long string"); // 缓冲区溢出！这是C语言中最经典的漏洞模式之一。虽然现代编译器（如GCC的-Wformat-overflow）能在编译期发现一些明显的溢出，但动态生成的格式字符串或运行时才知道长度的输入，编译器无能为力。
4.2 snprintf的安全机制：截断而非溢出
snprintf的签名是int snprintf(char *str, size_t size, const char *format, ...)。它多了一个size参数，指定缓冲区的最大容量。当格式化结果超过size - 1时，snprintf会截断输出，并保证缓冲区以\0结尾。
char buf[10]; int n = snprintf(buf, sizeof(buf), "%s", "this is a very long string"); // buf 包含 "this is a"（9个字符 + \0） // n = 26（如果缓冲区足够大，本应写入的字符数）注意snprintf的返回值：它返回的是"如果缓冲区足够大，本应写入的字符数"，而不是实际写入的字符数。这个设计允许你检测截断是否发生：
if (n >= (int)sizeof(buf)) { // 发生了截断，需要更大的缓冲区 }这个特性在动态分配缓冲区的场景下非常有用：先用snprintf(NULL, 0, ...)计算出所需长度，再分配内存，再调用一次snprintf写入。
int len = snprintf(NULL, 0, "Name: %s, Age: %d", name, age); char *buf = malloc(len + 1); snprintf(buf, len + 1, "Name: %s, Age: %d", name, age);4.3 格式化字符串的安全隐患：%n与用户输入
sprintf和snprintf的格式字符串如果来自用户输入，会带来严重的安全问题。攻击者可以构造包含%n的格式字符串，向任意内存地址写入数据；或者用%s读取栈上的敏感信息。
char user_input[] = "%n"; // 恶意输入 printf(user_input); // 危险！应该用 printf("%s", user_input)正确的做法是：永远不要把用户输入直接作为格式字符串。如果必须动态构造格式，使用白名单校验，确保只包含预期的格式说明符。
另一个容易被忽视的点是%s与NULL指针。printf("%s", NULL)在大多数平台上会导致崩溃，但有些平台会输出(null)。如果你的代码可能传入NULL，需要显式检查。
4.4 格式化输出的性能考量：snprintf vs 字符串拼接
在性能敏感的场景下，snprintf的开销不容忽视。它需要解析格式字符串、处理可变参数、进行类型转换。如果只是简单的字符串拼接，直接用memcpy或strcat可能更快。
但snprintf的优势在于安全性和可读性。在大多数业务场景下，这点性能差异可以忽略。只有在每秒调用数百万次的热路径上，才需要考虑用更底层的拼接方式替代。
一个实用的优化技巧是：如果格式化结果的长度可以预先估算，使用栈上的固定缓冲区（如char buf[256]）配合snprintf，避免堆分配。只有在长度不确定或可能很大时，才使用动态分配。
5. strtok的切分逻辑：为什么它不是线程安全的
5.1 strtok的内部状态：静态变量带来的隐患
strtok的函数签名是char *strtok(char *str, const char *delim)。第一次调用时传入待切分的字符串，后续调用传入NULL，函数会继续从上一次的位置切分。
char str[] = "apple,banana,cherry"; char *token = strtok(str, ","); while (token != NULL) { printf("%s\n", token); token = strtok(NULL, ","); }strtok之所以能在多次调用之间保持状态，是因为它内部使用了一个静态变量来记录当前位置。这个静态变量是strtok不是线程安全、不可重入的根本原因。
如果两个线程同时调用strtok，它们会互相干扰对方的切分位置，导致结果错乱。同样，如果在切分过程中嵌套调用strtok（比如在循环体内又调用了一次strtok切分另一个字符串），外层循环的状态会被破坏。
5.2 strtok_r与strtok_s：可重入的替代方案
POSIX标准提供了strtok_r，它是strtok的可重入版本：
char *saveptr; char *token = strtok_r(str, ",", &saveptr); while (token != NULL) { printf("%s\n", token); token = strtok_r(NULL, ",", &saveptr); }strtok_r把内部状态通过saveptr参数暴露给调用者，每个线程或每个切分任务维护自己的saveptr，互不干扰。
Windows平台提供了strtok_s，功能类似但签名略有不同。在跨平台项目中，通常需要用宏来统一接口：
#ifdef _WIN32 #define strtok_r strtok_s #endif5.3 strtok的连续分隔符处理：一个容易误解的行为
strtok会跳过连续的分隔符。比如用,切分"a,,b"，得到的是"a"和"b"，中间的空字段被忽略了。这个行为在某些场景下是期望的（比如解析CSV时忽略空列），但在另一些场景下会导致数据丢失。
如果你需要保留空字段，strtok就不适用了。替代方案是手动遍历字符串，或者使用strsep（BSD扩展，POSIX不保证可用）。
char *strsep(char **stringp, const char *delim);strsep不会跳过连续分隔符，每次调用返回一个字段（可能为空字符串）。但strsep也有自己的问题：它会修改原字符串，把分隔符替换为\0，而且不是标准C函数。
5.4 现代C++的替代方案：stringstream与string_view
在C++中，std::stringstream配合std::getline是更安全的切分方式：
#include <sstream> #include <string> std::stringstream ss("apple,banana,cherry"); std::string token; while (std::getline(ss, token, ',')) { // 处理 token }std::getline不会跳过空字段，也不会修改原字符串，且完全线程安全。缺点是性能不如strtok（涉及内存分配和流状态管理），但在大多数场景下足够用。
C++17的std::string_view配合手动查找可以写出高性能且安全的切分代码：
#include <string_view> void split(std::string_view sv, char delim) { size_t start = 0; while (start <= sv.size()) { size_t end = sv.find(delim, start); if (end == std::string_view::npos) end = sv.size(); std::string_view token = sv.substr(start, end - start); // 处理 token start = end + 1; } }这种方式不修改原字符串、不分配内存、线程安全，是高性能场景下的首选。
6. 实战中的组合拳：解析配置文件与协议报文的完整方案
6.1 配置文件解析：从fgets到strtol的完整链路
假设我们要解析一个简单的配置文件，格式如下：
port = 8080 timeout = 30.5 name = my_server完整的解析代码需要组合多个函数：
#include <stdio.h> #include <stdlib.h> #include <string.h> #include <errno.h> int parse_config(const char *filename) { FILE *fp = fopen(filename, "r"); if (!fp) return -1; char line[256]; while (fgets(line, sizeof(line), fp)) { // 跳过空行和注释 char *p = line; while (*p == ' ' || *p == '\t') p++; if (*p == '\0' || *p == '\n' || *p == '#') continue; // 用strtok_r切分key和value char *saveptr; char *key = strtok_r(p, "=", &saveptr); char *value = strtok_r(NULL, "\n", &saveptr); if (!key || !value) continue; // 去除key和value的首尾空白 // ...（省略trim函数实现） if (strcmp(key, "port") == 0) { char *endptr; errno = 0; long port = strtol(value, &endptr, 10); if (errno == ERANGE || *endptr != '\0' || port < 1 || port > 65535) { fprintf(stderr, "Invalid port: %s\n", value); fclose(fp); return -2; } // 保存port } else if (strcmp(key, "timeout") == 0) { char *endptr; errno = 0; double timeout = strtod(value, &endptr); if (errno == ERANGE || *endptr != '\0' || timeout <= 0) { fprintf(stderr, "Invalid timeout: %s\n", value); fclose(fp); return -3; } // 保存timeout } // ... 处理其他key } fclose(fp); return 0; }这段代码展示了几个关键点：fgets读取行（比gets安全，因为指定了缓冲区大小）；strtok_r切分key和value（可重入）；strtol和strtod做转换并检查错误；对转换结果做业务层面的范围校验。
6.2 协议报文解析：sscanf与手动解析的取舍
对于格式固定的协议报文，sscanf可以快速提取字段：
char packet[] = "CMD:LOGIN USER:alice PASS:secret123"; char cmd[16], user[32], pass[64]; int n = sscanf(packet, "CMD:%15s USER:%31s PASS:%63s", cmd, user, pass); if (n != 3) { // 解析失败 }注意格式字符串中的宽度限制（%15s、%31s、%63s），这是防止缓冲区溢出的关键。如果不加宽度限制，sscanf会一直读取直到遇到空白字符，可能超出目标缓冲区。
但sscanf的格式字符串如果与输入不完全匹配，可能导致解析错误或部分解析。对于复杂的协议，手动解析（用strstr、strchr定位字段）往往更可控。
6.3 日志格式化：snprintf的安全拼接模式
日志输出是snprintf的典型应用场景：
void log_message(const char *level, const char *format, ...) { char buf[1024]; int offset = 0; offset += snprintf(buf + offset, sizeof(buf) - offset, "[%s] ", level); va_list args; va_start(args, format); offset += vsnprintf(buf + offset, sizeof(buf) - offset, format, args); va_end(args); // 确保换行 if (offset < (int)sizeof(buf) - 1) { buf[offset++] = '\n'; buf[offset] = '\0'; } fputs(buf, stderr); }这个模式的关键是：每次snprintf都传入剩余缓冲区的大小（sizeof(buf) - offset），确保不会溢出。vsnprintf是snprintf的可变参数版本，适合封装成日志函数。
6.4 性能对比：各函数在百万次调用下的表现
我在一台普通开发机上做了一个简单的基准测试，解析100万次相同的输入，结果如下（仅供参考，实际性能因平台和编译器而异）：
| 函数 | 耗时（ms） | 相对速度 |
|---|---|---|
atoi | 12 | 1.0x |
strtol | 28 | 2.3x |
std::stoi | 45 | 3.8x |
std::from_chars | 10 | 0.8x |
sscanf | 180 | 15x |
strtod | 85 | 7x |
atoi最快，但不安全；strtol稍慢但提供了完整的错误检测；std::stoi因为异常机制的开销更慢；std::from_chars最快且安全，但需要C++17；sscanf最慢，因为需要解析格式字符串。
这个测试结果告诉我们：在性能敏感的场景下，sscanf应该尽量避免；strtol系列是安全与性能的平衡点；如果编译器支持C++17，std::from_chars是最优选择。
7. 那些年我踩过的转换函数坑：真实案例与修复过程
7.1 案例一：atoi导致的负数溢出
在一个处理传感器数据的项目中，我用atoi解析从设备读取的数值。设备偶尔会返回一个超出int范围的异常值（比如999999999999），atoi在这种情况下返回了一个未定义的值——在我的平台上恰好是-1。这个-1被当作合法数据写入了数据库，导致后续的统计分析出现严重偏差。
修复方案：改用strtol，检查errno == ERANGE，并对转换结果做范围校验。
char *endptr; errno = 0; long val = strtol(str, &endptr, 10); if (errno == ERANGE || val < INT_MIN || val > INT_MAX) { // 记录错误，跳过这条数据 }这个坑的教训是：永远不要假设外部输入是合法的。设备、网络、用户输入都可能产生异常值，atoi的"静默失败"会让问题隐藏很久才暴露。
7.2 案例二：strtok在嵌套循环中的状态污染
在一个解析多层配置的代码中，我在外层用strtok切分段落，内层用strtok切分键值对。结果外层循环在第二次迭代时就崩溃了——因为内层的strtok调用覆盖了外层的静态状态。
修复方案：外层用strtok_r，内层也用strtok_r，各自维护独立的saveptr。
char *outer_save; char *section = strtok_r(config, ";", &outer_save); while (section) { char *inner_save; char *kv = strtok_r(section, ",", &inner_save); while (kv) { // 处理键值对 kv = strtok_r(NULL, ",", &inner_save); } section = strtok_r(NULL, ";", &outer_save); }这个坑的教训是：只要涉及嵌套切分或多线程，就必须用strtok_r。strtok只适合最简单的单层切分场景。
7.3 案例三：snprintf返回值误用导致的缓冲区越界
我曾经写过这样的代码：
char buf[100]; int n = snprintf(buf, sizeof(buf), "%s", long_string); char *p = buf + n; // 危险！n可能大于sizeof(buf)当long_string超出缓冲区容量时，snprintf返回的是"本应写入的长度"，而不是实际写入的长度。用这个返回值做指针运算，会越界访问。
修复方案：用n >= sizeof(buf)判断是否截断，如果需要完整输出，动态分配足够的内存。
int n = snprintf(NULL, 0, "%s", long_string); char *buf = malloc(n + 1); snprintf(buf, n + 1, "%s", long_string);这个坑的教训是：snprintf的返回值不是实际写入长度，而是"理想长度"。这个设计虽然巧妙，但容易误用。
7.4 案例四：strtod的locale依赖问题
在一个跨国项目中，欧洲用户反馈配置文件解析失败。排查后发现：在某些locale下，strtod期望的小数点是逗号而不是点号。用户输入的3.14被解析为3，后面的.14被当作尾部垃圾。
修复方案：在解析前设置locale为"C"，或者使用不依赖locale的解析函数（如C++17的std::from_chars）。
#include <locale.h> setlocale(LC_NUMERIC, "C"); double d = strtod("3.14", NULL);这个坑的教训是：strtod、sscanf、sprintf等函数的行为受locale影响。在跨平台、跨地区的项目中，必须显式设置locale或使用不依赖locale的替代方案。
8. 写给不同阶段开发者的实用建议
如果你刚开始接触C/C++，我的建议是：先忘记atoi和atof。直接从strtol和strtod开始学起，养成检查endptr和errno的习惯。虽然代码会多几行，但这个习惯会让你在后续的职业生涯中避免无数个深夜调试。
如果你已经有一定经验，但在选型上还是"凭感觉"，建议你花时间整理一份自己的决策清单。比如：需要错误检测吗？需要跨平台吗？性能敏感吗？输入可信吗？把这些问题的答案和函数选型对应起来，形成条件反射。
如果你在做高性能系统开发，std::from_chars值得深入研究。它不抛异常、不分配内存、不依赖locale，是目前C++标准库中最快的字符串转数字方案。但它的接口比较底层，需要自己处理错误码和边界条件。
最后，无论你处于哪个阶段，都建议在代码审查中特别关注字符串转换相关的代码。这类代码往往看起来简单，但隐藏的坑最多。一个atoi调用、一个strtok的嵌套使用、一个snprintf返回值的误用，都可能成为线上事故的根源。把这些细节做好，你的代码质量会有肉眼可见的提升。
