企业官网建设流程全解析

1. 项目概述：从零构建一个C++图床云存储服务

最近在整理个人博客和项目文档时，图片管理一直是个头疼的问题。用第三方图床总担心服务不稳定或政策变化，自己搭又觉得太复杂。于是，我决定用C++手搓一个轻量级的图床共享云存储服务，核心目标就四个：用户能注册登录、服务端能安全地签发和验证token、上传的文件能按需排序展示，并且整个架构要清晰、高效、可扩展。这不仅仅是实现几个功能，更是对现代C++网络编程、数据安全和服务设计的一次深度实践。如果你也在寻找一个不依赖庞大框架、能从底层理解Web服务运作原理的项目，或者想给自己的工具链增加一个自托管的图片管理方案，那这个系列会非常适合你。我们将从Socket通信开始，一步步构建起包含用户认证、文件管理和API接口的完整后端系统。

2. 核心架构设计与技术选型

2.1 为什么选择C++而非更流行的Web语言？

第一个要回答的问题就是：为什么是C++？现在做Web服务，Go、Python、Java似乎是更主流的选择。我的考量主要有三点：性能控制、学习深度和资源占用。这个图床服务虽然功能不复杂，但涉及到文件I/O、网络并发和可能的图片实时处理（如缩略图生成），C++能让我对内存和CPU周期有极致的掌控力。其次，我想避开像Django、Spring Boot这样“全家桶”式的框架，从HTTP报文解析、路由分发到数据库连接池都自己实现或轻量级封装，这对于深入理解Web协议和服务器工作原理大有裨益。最后，我希望最终产出的服务是一个静态链接的、依赖极少的单一可执行文件，可以轻松部署在任何Linux环境，C++在这方面有着天然优势。

基于这些考虑，我的技术栈如下：

• 网络库：使用Boost.Asio。它是C++中异步I/O的事实标准，提供了跨平台的socket、定时器和信号处理能力，能帮助我们构建高性能的、事件驱动的服务器，避免自己陷入底层系统调用的泥潭。
• HTTP解析：手写一个简单的HTTP请求/响应解析器。虽然市面上有cpp-httplib、drogon等优秀库，但为了学习，我决定从零开始解析HTTP头部和主体，这能让你彻底明白一个HTTP POST请求是如何携带表单数据和文件二进制流的。
• 数据存储：用户信息和文件元数据使用SQLite。它无需单独部署服务，零配置，通过一个.db文件就能管理所有关系型数据，非常适合轻量级应用。而上传的图片文件本身，则直接存储在服务器的特定目录下，通过数据库记录其路径、文件名、大小、上传时间等元信息。
• Token认证：采用JWT (JSON Web Token)。用户登录成功后，服务端生成一个包含用户ID和过期时间的JWT token返回给客户端。客户端后续请求在HTTP头部携带此token，服务端验证其有效性和签名，即可完成身份鉴权。这实现了无状态的认证，避免了服务端存储Session的麻烦。
• 排序功能：文件列表的排序逻辑将在服务端实现。根据前端传递的排序参数（如按上传时间、文件大小、文件名），在数据库查询时通过ORDER BY子句完成，然后将排序后的结果封装成JSON返回。

2.2 系统模块划分与数据流

整个后端服务可以划分为以下几个核心模块，它们协同工作的数据流构成了服务的骨架：

1. 网络通信模块 (Network Layer)：基于Boost.Asio，监听特定端口（如8080），接受TCP连接。对于每个连接，异步读取HTTP请求的原始数据。
2. HTTP协议模块 (HTTP Parser)：将读取到的原始字节流，按照HTTP/1.1协议规范，解析出请求方法（GET/POST）、URL路径、请求头（Headers）和请求体（Body）。对于文件上传，需要特别处理multipart/form-data格式的Body。
3. 路由分发模块 (Router)：根据解析出的URL路径（如/api/register,/api/upload），将请求分发到对应的处理函数（Handler）。
4. 业务逻辑模块 (Business Logic)：
   • 用户服务：处理/api/register（注册）和/api/login（登录）。注册时需要校验用户名唯一性、密码强度，并将加盐哈希后的密码存入数据库。登录时验证密码，成功后生成JWT。
   • 认证中间件：对于需要认证的接口（如/api/upload,/api/files），在路由分发后、业务逻辑前，插入一个中间件。该中间件从请求头Authorization: Bearer <token>中提取JWT，进行签名验证和过期检查。验证通过则将解码出的用户ID注入到请求上下文中，供后续业务使用。
   • 文件服务：处理/api/upload（接收文件并存储到磁盘，记录元数据到DB）、/api/files（根据用户ID查询其文件列表，并支持按不同字段排序返回）。
5. 数据访问模块 (Data Access)：封装对SQLite数据库的所有操作，提供用户CRUD和文件元数据CRUD的接口。这里会涉及连接池的管理，以应对并发请求。
6. 响应组装模块 (Response Builder)：业务逻辑处理完毕后，将结果（成功的数据或错误信息）按照JSON格式组装，并设置正确的HTTP状态码（200 OK, 400 Bad Request, 401 Unauthorized等）和头部（如Content-Type: application/json），最后通过Asio写回给客户端。

整个数据流可以概括为：Socket接收数据 -> HTTP解析 -> 路由匹配 -> (认证拦截) -> 业务处理 -> 数据库操作 -> 构建JSON响应 -> Socket发送数据。这是一个清晰的、管道式的处理流程。

3. 核心功能实现细节拆解

3.1 用户注册与登录的安全实践

用户系统的核心是安全。绝对不能明文存储密码。

注册流程实现：

1. 客户端POST/api/register， Body为JSON格式：{"username":"test", "password":"123456", "email":"test@example.com"}。
2. 服务端校验数据：用户名是否已存在、密码长度和复杂度（至少6位，包含字母数字）、邮箱格式。
3. 密码加密：这是关键步骤。使用bcrypt或PBKDF2算法。我选择bcrypt，因为它内置了盐（salt）并且计算速度慢，能有效抵御彩虹表攻击。C++中可以使用libbcrypt库。

   // 伪代码示例：使用bcrypt生成密码哈希 #include <bcrypt/BCrypt.hpp> std::string hashPassword(const std::string& plainPassword) { // bcrypt会自动生成一个随机的salt并包含在最终的hash字符串中 std::string hash = BCrypt::generateHash(plainPassword, 12); // 12是工作因子，值越大越安全也越慢 return hash; // 返回的字符串格式类似 "$2a$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW" }

4. 将用户名、哈希后的密码、邮箱、创建时间存入users表。
5. 返回注册成功信息，切记不要返回密码哈希值。

登录流程实现：

1. 客户端POST/api/login， Body为JSON：{"username":"test", "password":"123456"}。
2. 服务端根据用户名从users表查询出对应的密码哈希字符串。
3. 使用bcrypt的验证函数，将客户端传来的明文密码与数据库存储的哈希值进行比对。

   bool checkPassword(const std::string& plainPassword, const std::string& storedHash) { return BCrypt::validatePassword(plainPassword, storedHash); }

4. 如果验证通过，则进入Token生成环节。

关键心得：盐（Salt）的重要性即使使用bcrypt（自带盐），理解“盐”的概念也至关重要。盐是一个随机字符串，在哈希前与密码拼接。它的目的是确保即使两个用户密码相同，其哈希值也完全不同，防止攻击者用预先计算好的哈希表（彩虹表）一次破解多个账户。bcrypt的哈希结果中已经包含了算法版本、工作因子和盐，所以我们只需要存储这个完整的字符串即可。

3.2 JWT Token的生成、签发与验证机制

登录成功后，我们需要创建一个代表用户身份的“通行证”——JWT Token。

JWT结构：它由三部分组成，用点分隔：Header.Payload.Signature。

• Header：通常包含令牌类型（typ: "JWT"）和签名算法（alg: "HS256"），进行Base64Url编码。
• Payload：存放声明（Claims），例如用户ID (sub: "user123")、过期时间 (exp: 1735689600)、签发时间 (iat: 1735686000)等。这部分也是Base64Url编码。注意：Payload只是编码，并非加密，所以不要存放密码等敏感信息。
• Signature：对编码后的Header和Payload，使用服务端持有的一个密钥（Secret）和Header中指定的算法（如HMAC SHA256）进行签名，用于验证消息在传输过程中未被篡改。

C++中的实现：我们可以使用jwt-cpp这个库。

#include <jwt-cpp/jwt.h> #include <chrono> std::string generateToken(int userId, const std::string& secret) { auto now = std::chrono::system_clock::now(); auto expire = now + std::chrono::hours(24); // Token 24小时后过期 auto token = jwt::create() .set_issuer("my-image-bed") .set_subject(std::to_string(userId)) // 用户ID作为主题 .set_issued_at(std::chrono::system_clock::to_time_t(now)) .set_expires_at(std::chrono::system_clock::to_time_t(expire)) .sign(jwt::algorithm::hs256{secret}); // 使用HS256算法和密钥签名 return token; }

生成的token类似：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJteS1pbWFnZS1iZWQiLCJzdWIiOiIxMjMiLCJpYXQiOjE3MzU2ODYwMDAsImV4cCI6MTczNTY5NDgwMH0.xxxxxx。服务端将其返回给客户端（通常放在JSON响应体中，如{"token": "xxx"}）。

客户端使用：客户端（如网页前端）收到token后，需要将其存储起来（通常用localStorage或sessionStorage）。在后续需要认证的请求中，在HTTP请求头中添加：Authorization: Bearer <your_token>。

服务端验证：对于需要认证的接口，服务端中间件会：

1. 从Authorization头中提取token。
2. 使用相同的密钥和算法验证token的签名是否有效。
3. 验证token是否过期（检查exp字段）。
4. 如果全部通过，从sub字段解析出用户ID，并将其存入本次请求的上下文（比如一个全局的request_context对象），供后续的业务逻辑使用。

bool verifyToken(const std::string& token, const std::string& secret, int& outUserId) { try { auto decoded = jwt::decode(token); auto verifier = jwt::verify() .allow_algorithm(jwt::algorithm::hs256{secret}) .with_issuer("my-image-bed"); verifier.verify(decoded); // 验证签名和发行者 // 验证过期时间（jwt-cpp的verify默认会检查exp） // 提取用户ID outUserId = std::stoi(decoded.get_subject()); return true; } catch (const std::exception& e) { // 验证失败：签名错误、过期、格式无效等 std::cerr << "Token verification failed: " << e.what() << std::endl; return false; } }

3.3 文件上传与存储策略

文件上传是图床的核心。我们需要处理multipart/form-data格式的HTTP POST请求。

HTTP解析部分：这是难点。我们需要手动解析请求体，找到boundary分隔符，然后逐个部分解析。每个部分有自己的头部（如Content-Disposition: form-data; name="file"; filename="test.jpg"）和主体（文件的二进制数据）。我们需要从中提取出文件名和文件数据。这个过程需要仔细处理字节流，确保二进制数据不被损坏。

存储策略：

1. 磁盘存储：不建议将所有文件堆在一个目录。常见的做法是按日期或用户ID分目录存储。例如：uploads/2024/01/01/user_123/abc.jpg。这有助于文件系统管理和后期迁移。生成一个唯一的文件名（如UUID）来存储，可以避免文件名冲突。
2. 数据库记录：在files表中存储一条记录，包含：
   • id：主键。
   • user_id：上传者ID。
   • original_filename：原始文件名。
   • storage_path：在服务器上的存储路径（相对路径或绝对路径）。
   • file_size：文件大小（字节）。
   • mime_type：文件类型（如image/jpeg），从上传请求头或文件魔数判断。
   • upload_time：上传时间戳。
   • url：可访问的URL（可由存储路径映射生成，如https://your-domain.com/uploads/2024/01/01/user_123/abc.jpg）。

返回结果：上传成功后，将文件的元信息（特别是生成的访问URL）以JSON格式返回给客户端。客户端（如Markdown编辑器）就可以直接使用这个URL了。

3.4 文件列表查询与多维度排序实现

用户需要查看和管理自己上传的文件列表。接口设计为GET /api/files，需要认证（从token中获取user_id）。

数据库查询：这是一个典型的SELECT操作。

SELECT id, original_filename, file_size, mime_type, upload_time, url FROM files WHERE user_id = ? ORDER BY ? ? LIMIT ? OFFSET ?;

这里有两个关键点：

1. WHERE条件：只查询当前登录用户的文件，这是数据隔离的基础安全要求。
2. ORDER BY：排序子句。我们需要支持前端传递排序参数。

排序参数设计：前端可以通过查询字符串（Query String）传递排序字段和顺序，例如：/api/files?sort_by=upload_time&order=desc。

• sort_by：可选值upload_time（上传时间）、file_size（文件大小）、original_filename（文件名）。
• order：可选值asc（升序）、desc（降序）。

服务端处理：在C++代码中，绝对不能直接将前端传入的字符串拼接到SQL语句中，这会导致严重的SQL注入漏洞。正确的做法是使用参数化查询或白名单映射。

std::string mapSortField(const std::string& clientField) { static const std::unordered_map<std::string, std::string> fieldMap = { {"upload_time", "upload_time"}, {"file_size", "file_size"}, {"original_filename", "original_filename"} }; auto it = fieldMap.find(clientField); return (it != fieldMap.end()) ? it->second : "upload_time"; // 默认按时间排序 } std::string mapSortOrder(const std::string& clientOrder) { return (clientOrder == "asc") ? "ASC" : "DESC"; // 默认DESC } // 在构造SQL时使用映射后的安全字段名和顺序 std::string safeSortField = mapSortField(request.get_param("sort_by")); std::string safeSortOrder = mapSortOrder(request.get_param("order")); std::string sql = "SELECT ... ORDER BY " + safeSortField + " " + safeSortOrder + " ..."; // 然后使用SQLite的预处理语句绑定参数

通过白名单映射，我们确保了只有预定义的、安全的字段名和排序方式会被用于SQL语句。

分页：对于文件可能很多的情况，还需要实现分页。使用LIMIT和OFFSET子句，前端传递page和page_size参数。

响应格式：将查询结果集转换为JSON数组返回，每个文件是一个JSON对象。

4. 关键模块的C++代码实现与解析

4.1 基于Boost.Asio的简易HTTP服务器框架

我们首先搭建一个能处理并发连接的HTTP服务器骨架。这里使用Boost.Asio的异步模式。

#include <boost/asio.hpp> #include <iostream> #include <memory> #include <thread> #include <vector> using boost::asio::ip::tcp; class HttpSession : public std::enable_shared_from_this<HttpSession> { public: HttpSession(tcp::socket socket) : socket_(std::move(socket)) {} void start() { doRead(); } private: void doRead() { auto self(shared_from_this()); socket_.async_read_some(boost::asio::buffer(data_, max_length), [this, self](boost::system::error_code ec, std::size_t length) { if (!ec) { // 1. 在这里解析收到的数据(data_) std::string request(data_, length); // 2. 调用HTTP解析器，得到请求方法、路径、头部、体 // 3. 根据路径路由到对应的处理函数 auto response = handleRequest(parsedRequest); // 4. 异步写回响应 doWrite(response); } }); } void doWrite(const std::string& response) { auto self(shared_from_this()); boost::asio::async_write(socket_, boost::asio::buffer(response), [this, self](boost::system::error_code ec, std::size_t /*length*/) { if (!ec) { // 写入完成，可以关闭连接或保持keep-alive（需要解析Connection头） boost::system::error_code ignored_ec; socket_.shutdown(tcp::socket::shutdown_both, ignored_ec); } }); } tcp::socket socket_; enum { max_length = 8192 }; // 缓冲区大小 char data_[max_length]; // 需要添加HTTP解析器、路由表等成员 }; class HttpServer { public: HttpServer(boost::asio::io_context& io_context, short port) : acceptor_(io_context, tcp::endpoint(tcp::v4(), port)) { doAccept(); } private: void doAccept() { acceptor_.async_accept( [this](boost::system::error_code ec, tcp::socket socket) { if (!ec) { std::make_shared<HttpSession>(std::move(socket))->start(); } doAccept(); // 继续接受新连接 }); } tcp::acceptor acceptor_; };

这个框架提供了异步处理连接的基础。HttpSession类代表一次客户端会话，在其doRead回调中，我们需要实现HTTP协议的解析和业务路由。这是一个最简化的模型，实际中需要处理长连接、请求体过大、超时等复杂情况。

4.2 手动解析multipart/form-data文件上传

解析multipart/form-data是文件上传的难点。下面展示核心解析逻辑的伪代码思路：

struct FormDataPart { std::unordered_map<std::string, std::string> headers; std::vector<char> body; // 对于文件，这里就是二进制内容 std::string name; // 表单字段名 std::string filename; // 如果是文件，则有文件名 }; std::vector<FormDataPart> parseMultipartFormData(const std::string& body, const std::string& boundary) { std::vector<FormDataPart> parts; std::string delimiter = "--" + boundary; std::string endDelimiter = delimiter + "--"; size_t pos = 0; // 跳过首部的boundary pos = body.find(delimiter, pos); if (pos == std::string::npos) return parts; pos += delimiter.length(); while (pos < body.length()) { // 1. 跳过CRLF if (body.substr(pos, 2) == "\r\n") pos += 2; // 2. 解析Part头部 FormDataPart part; size_t headerEnd = body.find("\r\n\r\n", pos); if (headerEnd == std::string::npos) break; std::string headerBlock = body.substr(pos, headerEnd - pos); pos = headerEnd + 4; // 跳过"\r\n\r\n" // 解析头部字符串，获取Content-Disposition等，提取name和filename // ... // 3. 解析Part主体 size_t partEnd = body.find(delimiter, pos); if (partEnd == std::string::npos) partEnd = body.find(endDelimiter, pos); if (partEnd == std::string::npos) break; // 主体结束位置前有2个字节的CRLF（如果是最后一个part，则没有） size_t bodyLength = partEnd - pos; if (bodyLength >= 2 && body.substr(partEnd - 2, 2) == "\r\n") { bodyLength -= 2; } part.body.assign(body.begin() + pos, body.begin() + pos + bodyLength); parts.push_back(part); pos = partEnd; // 如果遇到结束分隔符，跳出循环 if (body.substr(pos, endDelimiter.length()) == endDelimiter) break; } return parts; }

在实际处理中，我们需要从HTTP请求的Content-Type头中提取boundary值（如boundary=----WebKitFormBoundaryABC123），然后将整个请求体（可能是二进制数据）传递给这个解析函数。解析出的FormDataPart，如果filename不为空，则是一个文件，我们需要将其body（std::vector<char>）写入磁盘；如果filename为空，则是一个普通表单字段。

4.3 SQLite数据库操作封装与连接池

对于轻量级应用，SQLite的并发读写能力是足够的，但为了优化，我们可以实现一个简单的连接池。

#include <sqlite3.h> #include <queue> #include <mutex> #include <memory> class SQLiteConnectionPool { public: static SQLiteConnectionPool& getInstance() { static SQLiteConnectionPool instance("image_bed.db"); return instance; } std::shared_ptr<sqlite3> getConnection() { std::unique_lock<std::mutex> lock(mutex_); if (connections_.empty()) { // 如果池为空，创建新连接（可以设置上限） sqlite3* rawConn = nullptr; if (sqlite3_open(dbPath_.c_str(), &rawConn) != SQLITE_OK) { throw std::runtime_error("Failed to open database"); } // 设置一些PRAGMA，如启用外键、WAL模式提升并发 sqlite3_exec(rawConn, "PRAGMA foreign_keys = ON;", nullptr, nullptr, nullptr); sqlite3_exec(rawConn, "PRAGMA journal_mode = WAL;", nullptr, nullptr, nullptr); return std::shared_ptr<sqlite3>(rawConn, [](sqlite3* conn) { // 自定义删除器：不关闭，而是放回池中 SQLiteConnectionPool::getInstance().returnConnection(conn); }); } else { auto conn = connections_.front(); connections_.pop(); return std::shared_ptr<sqlite3>(conn, [](sqlite3* conn) { SQLiteConnectionPool::getInstance().returnConnection(conn); }); } } void returnConnection(sqlite3* conn) { std::unique_lock<std::mutex> lock(mutex_); connections_.push(conn); } private: SQLiteConnectionPool(const std::string& dbPath) : dbPath_(dbPath) { // 初始化时创建一些连接 for (int i = 0; i < initialPoolSize_; ++i) { sqlite3* conn = nullptr; if (sqlite3_open(dbPath_.c_str(), &conn) == SQLITE_OK) { sqlite3_exec(conn, "PRAGMA foreign_keys = ON;", nullptr, nullptr, nullptr); sqlite3_exec(conn, "PRAGMA journal_mode = WAL;", nullptr, nullptr, nullptr); connections_.push(conn); } } } ~SQLiteConnectionPool() { while (!connections_.empty()) { sqlite3_close(connections_.front()); connections_.pop(); } } std::string dbPath_; std::queue<sqlite3*> connections_; std::mutex mutex_; const int initialPoolSize_ = 5; };

这个连接池使用了单例模式。getConnection()返回一个std::shared_ptr<sqlite3>，并设置了自定义删除器，使得连接对象在智能指针析构时不会被sqlite3_close，而是调用returnConnection放回池中。这确保了连接的重用。在实际的业务代码中，可以这样使用：

auto conn = SQLiteConnectionPool::getInstance().getConnection(); sqlite3_stmt* stmt; std::string sql = "INSERT INTO users (username, password_hash) VALUES (?, ?)"; if (sqlite3_prepare_v2(conn.get(), sql.c_str(), -1, &stmt, nullptr) == SQLITE_OK) { sqlite3_bind_text(stmt, 1, username.c_str(), -1, SQLITE_STATIC); sqlite3_bind_text(stmt, 2, passwordHash.c_str(), -1, SQLITE_STATIC); sqlite3_step(stmt); sqlite3_finalize(stmt); } // conn 离开作用域，自动通过自定义删除器归还到连接池

使用预处理语句（sqlite3_prepare_v2）和参数绑定（sqlite3_bind_*）是防止SQL注入的最佳实践，务必在所有动态构造SQL的地方使用。

5. 部署、测试与性能调优要点

5.1 服务编译、部署与进程守护

编译：使用CMake管理项目是标准做法。确保链接必要的库：Boost::asio,sqlite3,jwt-cpp,bcrypt等。

cmake_minimum_required(VERSION 3.10) project(ImageBedServer) set(CMAKE_CXX_STANDARD 17) find_package(Boost REQUIRED COMPONENTS system) find_package(SQLite3 REQUIRED) # 假设jwt-cpp和libbcrypt通过FetchContent或find_library引入 add_executable(image_bed_server main.cpp http_server.cpp router.cpp auth.cpp database.cpp file_upload.cpp) target_link_libraries(image_bed_server PRIVATE Boost::asio ${SQLITE3_LIBRARIES} jwt-cpp bcrypt)

编译后得到一个单一的可执行文件image_bed_server。

部署：

1. 将可执行文件、数据库文件（如果新建）、配置文件、上传目录uploads/等打包。
2. 上传到服务器（如Ubuntu）。
3. 可以使用systemd来管理服务，实现开机自启和进程守护。创建一个服务文件/etc/systemd/system/image-bed.service：

   [Unit] Description=C++ Image Bed Service After=network.target [Service] Type=simple User=www-data # 或一个专用用户 WorkingDirectory=/opt/image_bed ExecStart=/opt/image_bed/image_bed_server Restart=on-failure RestartSec=5s [Install] WantedBy=multi-user.target

4. 使用命令启用并启动服务：

   sudo systemctl daemon-reload sudo systemctl enable image-bed sudo systemctl start image-bed sudo systemctl status image-bed # 查看状态

5.2 接口测试与安全审计

在开发过程中和上线前，必须进行全面的测试。

功能测试：使用curl或Postman等工具模拟客户端请求。

• 注册：curl -X POST http://localhost:8080/api/register -H "Content-Type: application/json" -d '{"username":"test","password":"123456","email":"test@example.com"}'
• 登录：curl -X POST http://localhost:8080/api/login -H "Content-Type: application/json" -d '{"username":"test","password":"123456"}'，保存返回的token。
• 上传文件（带token）：curl -X POST http://localhost:8080/api/upload -H "Authorization: Bearer YOUR_TOKEN_HERE" -F "file=@/path/to/your/image.jpg"
• 获取文件列表（带排序）：curl -X GET "http://localhost:8080/api/files?sort_by=file_size&order=asc" -H "Authorization: Bearer YOUR_TOKEN_HERE"

安全审计要点：

1. SQL注入：检查所有数据库操作是否都使用参数化查询（预处理语句）。
2. 目录遍历：检查文件上传和文件服务逻辑。确保用户提供的文件名或路径参数不会导致读取或写入服务器上的任意文件（如../../../etc/passwd）。存储路径应由服务端根据规则生成，不要使用用户提供的原始路径。
3. 认证与授权：测试未登录时访问/api/upload等接口是否返回401。测试用户A的token能否访问用户B的文件（通过修改URL中的ID等参数尝试越权）。
4. 文件类型校验：不要仅依赖客户端上传的MIME类型。服务端应通过检查文件内容的“魔数”（Magic Number）或使用库来验证文件确实是图片格式（如JPEG, PNG, GIF），防止上传伪装成图片的恶意脚本。
5. 文件大小限制：在HTTP解析阶段或业务逻辑中，对上传的文件大小进行限制，防止DoS攻击。
6. Token安全：确保JWT密钥（Secret）足够长且随机，并妥善保管（不要硬编码在代码中，应通过环境变量或配置文件读取）。验证Token时检查过期时间。

5.3 性能瓶颈分析与优化策略

对于一个自用的图床，这个架构的性能通常足够。但如果考虑公开服务或更大规模，需要注意以下几点：

1. I/O瓶颈：
   • 磁盘I/O：文件上传下载是主要的I/O操作。使用SSD硬盘能极大提升性能。对于读多写少的场景，可以考虑将uploads/目录挂载到内存盘（tmpfs）或使用CDN分发静态文件。
   • 网络I/O：使用异步I/O（Asio）本身就是为了高效利用网络。可以调整TCP内核参数（如net.core.somaxconn）来优化并发连接处理能力。
2. CPU瓶颈：
   • 图片处理：如果未来需要生成缩略图、添加水印，这些操作是CPU密集型的。可以考虑引入线程池，将图片处理任务丢到后台线程，避免阻塞网络I/O线程。
   • 哈希与加密：bcrypt哈希和JWT签名验证也有一定CPU开销。确保工作因子（cost factor）设置合理（通常10-12是平衡点）。对于超高并发登录，这可能成为瓶颈，但对我们的小型服务来说问题不大。
3. 内存与连接数：
   • Boost.Asio的每个异步操作都可能关联一个回调对象。确保你的代码中没有意外的内存泄漏（使用智能指针管理资源）。
   • 连接池的大小需要根据实际并发数调整。太小会导致等待，太大浪费资源。可以设计成动态伸缩的连接池。
4. 数据库优化：
   • 为files表的user_id和upload_time字段创建索引，可以大幅加速WHERE user_id=? ORDER BY upload_time这类查询。

   CREATE INDEX idx_files_user_time ON files(user_id, upload_time); CREATE INDEX idx_files_user_size ON files(user_id, file_size);

   • 定期清理无效的数据库连接（虽然连接池管理了大部分）。
5. 异步处理：对于文件上传后的处理（如生成缩略图、写入数据库），如果耗时较长，可以考虑将其放入一个内部任务队列，立即返回“上传成功”响应给客户端，然后由后台工作线程异步处理这些任务。这能显著提升接口的响应速度。

这个项目从零开始构建，涵盖了网络、协议、安全、存储、数据库等多个方面，是一个非常好的C++全栈实践。它没有使用任何重量级Web框架，让你能看清每一行代码背后的逻辑。完成之后，你不仅得到了一个可用的私有图床，更重要的是对如何构建一个安全的、高效的网络服务有了更深层次的理解。在实际编码中，错误处理、日志记录、配置化管理等都是需要进一步完善的地方，但核心骨架和思路已经在这里了。