查blob数据时不能用std::string直接接收，因其遇\0会截断；须用sqlite3_column_blob+sqlite3_column_bytes等获取原始指针与长度，并以二进制模式写入文件，大blob需分块流式处理。
查出BLOB数据时，别用std::string直接接
很多初学者看到数据库驱动（比如SQLite C++接口、MySQL Connector/C++）返回std::string类型的BLOB字段，就直接赋值保存，结果文件打不开或损坏。根本原因是：BLOB是二进制数据，可能含\0字节，而std::string在遇到\0时会截断；更糟的是，某些驱动底层用char* + 长度描述BLOB，但封装层错误地当成C字符串处理。
正确做法是明确获取原始指针和长度：
- SQLite3：用
sqlite3_column_blob(stmt, col_idx)+sqlite3_column_bytes(stmt, col_idx) - MySQL Connector/C++：用
getBlob()返回sql::Blob*，再调用getBytes()并传入length参数（不能只用getString()） - ODBC：用
SQLGetData()配合SQL_C_BINARY类型，并手动管理缓冲区大小
写入文件必须用std::ofstream的二进制模式
即使你拿到了完整的BLOB内存块，用默认构造的std::ofstream写入也会出错——Windows下会把\n转成\r\n，Linux虽不转换但标准库仍可能对\0敏感。必须显式指定std::ios::binary标志。
示例（安全写法）：
std::ofstream file("output.bin", std::ios::out | std::ios::binary);
if (file.is_open()) {
file.write(static_cast<const char>(blob_data), blob_length);
file.close();
}
</const>
注意：blob_data必须是const void*或const char*，不能是std::string::c_str()（除非你100%确认没\0且长度一致）。
大BLOB（>10MB）别一次性加载到内存
从数据库读取几百MB的BLOB到std::vector<uint8_t></uint8_t>里再写磁盘，容易触发OOM或让程序卡死。实际项目中应流式处理：
- SQLite3支持
sqlite3_blob_open()+sqlite3_blob_read()分块读取（每次几KB） - MySQL Connector/C++的
sql::Blob也提供setBytes()/getBytes()带offset/length重载，可循环调用 - 关键点：每次读取后立刻
write()到文件，不要累积
否则不仅内存爆，还可能因超时导致数据库连接中断（尤其网络DB如MySQL over TCP）。
文件名和路径要防注入，尤其来自数据库字段
如果BLOB对应的原始文件名存在数据库里（比如filename VARCHAR），直接拼接路径极危险：../../etc/passwd这种输入会导致覆盖系统文件。不能简单用std::filesystem::path拼接了事。
稳妥做法：
- 提取纯文件名（去掉路径部分）：用
std::filesystem::path(filename_from_db).filename().string() - 过滤非法字符：只保留
a-zA-Z0-9._-等安全字符，其余替换成_ - 强制加上扩展名白名单（如
.jpg,.pdf），或根据BLOB前几个字节（magic bytes）推断MIME后决定扩展名
跳过这步，导出功能在用户可控字段场景下等于开放任意文件写入漏洞。
边界情况比想象中多：BLOB为空、数据库字段为NULL、磁盘满、目录无写权限——这些都得检查write()返回值和file.fail()，不能只靠is_open()。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
