简介：C++ POCO 库中文文档面向希望补齐 C++ 标准库短板的开发者与嵌入式工程师，系统讲解这套开源类库的模块划分与具体用法。文档围绕以网络为中心的跨平台开发需求，梳理 Foundation、XML、Util、Net 四个核心库以及 NetSSL、Data 附加库各自负责什么，并逐项展开字符串裁剪与 UTF-8/UTF-16 编码转换、日期时间处理、Poco::File 与 Poco::Path、DirectoryIterator 文件系统访问、NotificationCenter 与 events 通知机制、BinaryReader 与 BinaryWriter 的字节序透明读写、支持过滤和多通道输出的日志框架，以及 SharedLibrary、ClassLoader 运行时插件加载等内容，同时涉及 Poco::Any、引用计数智能指针、内存池与线程同步封装。文件包仅含 1 个 PDF，约 8.3MB，方便通读或按模块检索。已有 1537 人学习，可作为日常查阅 API 与理解库设计思路的常备手册。

1. 一份 C++ POCO-lib 中文文档到底值不值得翻

很多人拿到《C++POCO-lib(中文文档).pdf》的第一反应是把它当 API 字典：写代码时想不起来Poco::Net::HTTPServer的构造函数有几个参数，Ctrl+F 搜一下。这种方式只发挥了它三成的作用。POCO-lib（POCO C++ Libraries）是一套分层很清晰的 C++ 基础库，Foundation 是骨架，Net 管通信，Util 管配置与生命周期，JSON/XML/Data 补齐数据面。中文文档真正的价值，是把这种分层意图用母语讲清楚了，你顺着目录读能建立心智地图，倒着读只能查到零散的函数签名。它适合手上已经有一个 C++ 服务端或工具类项目、不想从裸 socket 和 pthread 起手、又觉得重量级框架拖不动的人。不适合只想找一两个字符串工具函数的人，那种场景标准库就够了。

2. 从文档目录反推学习路径：Foundation 四个类族先吃透哪个

中文文档的页数摆在那里，从头翻到最后一页的完成率通常很低。更现实的做法是先给章节做一次价值排序，把「读一遍就能立刻用上」的部分前置，把「用到再回来看」的部分标成索引。这一章给出一张我实际用过的优先级映射，再落到 Foundation 里最该先啃的四个类族，最后用一个最小工程把文档示例变成能编译、能跑、能断点的东西。为什么从 Foundation 起手？因为 Net 里的每一个异常、每一次日志输出、每一个配置项类型，底子都在 Foundation 上，跳过它直接写网络代码，报错信息你连该去查哪一层都不知道。

2.1 文档章节该顺读还是倒查：一张优先级映射表

把中文文档的章节目录摊开来看，大致可以分成四档：立刻要读、用到再读、只当索引、可以暂时跳过。这个分档不是按难度排的，而是按「读完能不能马上改动你现有的代码」排的。

这张表最容易被忽略的一行是 Util。很多人的工程是先写业务再想启动参数，结果配置读取、日志初始化、优雅退出三件事散落在各处。POCO 的Poco::Util::Application把这套东西收拢成了一个模板方法，跟着文档走一遍，后面加任何子系统都是往里面挂。

2.2 数字、字符串、时间、文件系统：四个类族的依赖顺序

Foundation 里的类看着多，真正的高频核心就那么四组，而且它们之间存在自然的依赖顺序：数字和字符串是地基，时间是横切，文件系统依赖前三者。

第一组是数字与字符串互转。Poco::NumberParser负责把文本解析成数值，Poco::NumberFormatter负责反向输出，还带宽度、进制、精度控制。这两个类最常被低估的地方是错误处理——解析失败抛的是Poco::SyntaxException，不是返回默认值，所以调用点必须包 try/catch，否则线上一个脏配置就能让进程退出。

第二组是字符串工具。Poco::StringTokenizer处理分隔符拆分，Poco::toUpper/Poco::toLower/Poco::trim这组自由函数处理大小写和空白。文档里给了 flags 参数，TOK_TRIM去掉每个 token 两侧空白，TOK_IGNORE_EMPTY丢弃空 token，这两个组合起来基本覆盖了读取 CSV 行的需求。血泪经验是不要用std::string::find手写拆分，遇到连续分隔符和首尾分隔符时的边界处理非常容易翻车。

第三组是时间。POCO 把时间和时区拆成了Poco::Timestamp（UTC 时间轴上的一个点）、Poco::DateTime（UTC 的日历表示）、Poco::LocalDateTime（本地时区的日历表示）三个类型。文档里格式化那一节的示例直接用了Timestamp，但如果你要写日志时间戳，用的是LocalDateTime，否则输出的永远是 UTC，看日志的人会以为服务器时钟错了八小时。

第四组是文件系统。Poco::Path负责路径拼接与解析，Poco::File负责存在性判断、创建、遍历，Poco::DirectoryIterator负责目录遍历。核心原则只有一条：路径永远不要用字符串相加来拼，Path::append会按当前平台处理分隔符，Windows 和 Linux 的表现才对得上。

这四组的顺序不建议打乱。先把数值和字符串的异常行为摸清楚，再看时间格式化，最后碰文件系统，遇到报错时你才有能力判断问题出在解析、格式化还是 IO。

2.3 用一份最小工程验证文档示例能跑通

文档示例最大的问题不是错，而是缺上下文：头文件没写全、命名空间没写全、链接哪个库没说。抄下来编译不过，人就容易怀疑是不是文档太旧。正确的做法是先建一个只有 main 的空工程，把文档里四个类族各挑一个 API 塞进去，跑通一次，之后所有示例都往这个工程里加。

// main.cpp —— 四个 Foundation 类族各做一件事，验证文档示例可编译可运行 #include <Poco/DateTimeFormatter.h> #include <Poco/LocalDateTime.h> #include <Poco/NumberFormatter.h> #include <Poco/NumberParser.h> #include <Poco/Path.h> #include <Poco/StringTokenizer.h> #include <iostream> int main() { // 1) 字符串转数字：解析失败会抛 SyntaxException，不是返回 0 int n = Poco::NumberParser::parse("2048"); // 2) 数字转字符串：第二个参数是总宽度，右对齐补空格 std::string padded = Poco::NumberFormatter::format(n, 6); // 3) 切分：TOK_TRIM 去两侧空白，TOK_IGNORE_EMPTY 丢弃空串 Poco::StringTokenizer tok("a, b,,c", ",", Poco::StringTokenizer::TOK_TRIM | Poco::StringTokenizer::TOK_IGNORE_EMPTY); // 4) 路径拼接：不要用字符串相加，交给 Path 处理分隔符 Poco::Path p("/var/data"); p.append("run.log"); // 5) 本地时间格式化：用 LocalDateTime，Timestamp 输出的是 UTC std::string ts = Poco::DateTimeFormatter::format( Poco::LocalDateTime(), "%Y-%m-%d %H:%M:%S"); std::cout << padded << " | " << tok.count() << " tokens | " << p.toString() << " | " << ts << std::endl; return 0; }

逻辑说明：这一段刻意把五个 API 放在同一个函数里，没有任何业务逻辑，目的是让编译错误和运行错误一次暴露。第 1 步和第 2 步是一对，先解析再格式化，中间不做任何转换，这样如果输出不对，问题一定在这两个类上。第 3 步用了一个带连续逗号和空格的输入串，专门测 flags 组合有没有生效。第 4 步和第 5 步分别验证路径和时区，这两个是纯环境相关的问题，换个平台或换个时区就会暴露。

参数说明：NumberFormatter::format(int, int)的第二个参数是字段总宽度，不是小数位数，超过宽度会原样输出不截断。StringTokenizer的第三个参数是位掩码，可以任意或组合。Path::append(const std::string&)会判断传进来的片段是否已经是绝对路径，如果是就替换整个路径，这个行为在拼接用户输入的路径时是安全隐患，务必先用Path::isAbsolute拦一道。

# 编译：先只链 Foundation，看最低依赖能不能过 g++ -std=c++17 main.cpp -o demo \ $(pkg-config --cflags --libs PocoFoundation) || echo "Foundation 链接失败，先查安装" ./demo

这条命令的意义是把依赖压到最小。如果只链PocoFoundation就编不过，说明环境层面的安装有问题，跟你抄的示例对不对无关。等你确认最小工程能跑之后，再逐步把 Net、Util 的库加进来，每加一个跑一次，出问题时改动范围就是最后一次加的东西，比一次性全链上再排查要快得多。

3. 中文文档的网络章节怎么落地：Socket、Reactor 与 HTTPServer 三层选型

网络部分是 POCO 用得最多、也是文档最容易被读岔的部分。中文文档把Poco::Net::Socket、SocketReactor、HTTPServer并列来讲，看起来像三个可选项，实际上它们是三个层级，选错了不是写不出来，而是写出来之后线程模型和你的预期对不上。这一章先把三层的分界线划清楚，再重点拆 Reactor 的线程模型——文档里那一段如果读漏一句，你会写出表面并发、实际串行的代码。最后给一个能直接跑起来的 HTTP 服务端骨架，以及几个真正影响吞吐的参数。

3.1 三种网络抽象的分界线

Poco::Net::StreamSocket是最薄的一层，本质是对 BSD socket 的对象化封装，阻塞模式下读写语义和你手写 socket 完全一致。它的价值在于 RAII：析构自动 close，异常路径不会漏文件描述符，地址解析交给SocketAddress。

Poco::Net::SocketReactor是非阻塞事件循环，你注册回调，它负责 select/poll，连接可读可写时回调你。它不带线程，一个 reactor 就是一个线程在跑事件循环。

Poco::Net::HTTPServer是完整应用层，内部自己管 reactor、线程池、请求解析、响应生成、keep-alive，你只需要提供HTTPRequestHandler和HTTPRequestHandlerFactory。

三者的选择标准很干脆：

最常见的误用是拿 StreamSocket 开几百个线程去做长连接服务端。这种写法在小规模压测下看不出问题，连接数一上来，线程栈内存和调度开销就会把机器吃干净，表现出来是 CPU 不高但延迟飙升，很多人误以为是网络问题。

3.2 Reactor 的线程模型：读漏一段就会写出假并发

中文文档讲SocketReactor时有一句关键的话经常被略过：reactor 在调用run()的那个线程里执行事件循环，所有onSocketReadable之类的回调都在这个线程里串行执行。这句话的后果是：只要你的回调里做了一次阻塞 IO 或者一次慢查询，整个 reactor 上挂的所有连接都会被卡住。

正确的用法是「一个 reactor 一个线程，回调里只做搬数据，重活丢给工作队列」。POCO 里配合的是Poco::ThreadPool或自己的队列，回调里把读到的字节复制出来、投递任务、立刻返回。如果单 reactor 的吞吐顶不住，就开多个 reactor，每个绑一个线程，新连接按某种策略分给某个 reactor——文档里有把SocketReactor和Poco::Thread组合起来的示例，思路就是这样。

另一个容易踩的点是读写通知的语义。SocketNotification::READABLE只是告诉你「现在可读」，不告诉你「读多少」。回调里必须自己循环receiveBytes，直到返回 0（对端关闭）或者抛出Poco::TimeoutException（非阻塞下没有更多数据）。不少人的示例代码只读一次，本地测试用短报文完全正常，一上生产遇到分片报文就丢数据，这类问题排查起来非常费劲，因为日志里看不出任何异常。

还有一个隐性差异：HTTPServer在内部已经把这个模型包好了，它用TCPServer+HTTPServerConnection帮你管理连接和线程池，你在 handler 里写的是阻塞风格的代码，框架保证每个请求在一个线程里跑。所以如果你一开始就打算做 HTTP，不要绕过HTTPServer自己去拼 reactor，那是给自己找麻烦。

3.3 一个可复现的 HTTP 服务端骨架与参数调整

下面这段代码把Poco::Util::ServerApplication和HTTPServer拼在一起，收到 SIGINT/SIGTERM 会走waitForTerminationRequest返回，然后停掉服务，这是 POCO 里做后台服务的标准骨架。

// server.cpp —— 最小 HTTP 服务端：路由、响应、优雅退出 #include <Poco/Net/HTTPServer.h> #include <Poco/Net/HTTPRequestHandler.h> #include <Poco/Net/HTTPRequestHandlerFactory.h> #include <Poco/Net/HTTPServerRequest.h> #include <Poco/Net/HTTPServerResponse.h> #include <Poco/Net/HTTPResponse.h> #include <Poco/Net/ServerSocket.h> #include <Poco/Util/ServerApplication.h> class PingHandler : public Poco::Net::HTTPRequestHandler { public: void handleRequest(Poco::Net::HTTPServerRequest& req, Poco::Net::HTTPServerResponse& resp) override { resp.setStatus(Poco::Net::HTTPResponse::HTTP_OK); resp.setContentType("application/json"); std::ostream& out = resp.send(); // 必须先 send()，再写响应体 out << "{\"path\":\"" << req.getURI() << "\"}"; } }; class Router : public Poco::Net::HTTPRequestHandlerFactory { public: Poco::Net::HTTPRequestHandler* createRequestHandler(const Poco::Net::HTTPServerRequest& req) override { if (req.getURI() == "/ping") return new PingHandler; return nullptr; // 返回空，框架直接回 404 } }; class HttpApp : public Poco::Util::ServerApplication { protected: int main(const std::vector<std::string>&) override { auto* params = new Poco::Net::HTTPServerParams; params->setMaxQueued(256); // 等待队列上限 params->setMaxThreads(32); // 工作线程上限 params->setThreadIdleTime(Poco::Timespan(10, 0)); // 空闲线程存活 10s params->setKeepAlive(true); params->setKeepAliveTimeout(Poco::Timespan(15, 0)); // 长连接空闲超时 Poco::Net::ServerSocket ss(8080); Poco::Net::HTTPServer srv(new Router, ss, params); srv.start(); waitForTerminationRequest(); // 等信号，收到后往下走 srv.stop(); return Application::EXIT_OK; } }; POCO_SERVER_MAIN(HttpApp)

逻辑说明：createRequestHandler返回nullptr时框架直接生成 404，不用自己写错误处理。resp.send()返回输出流，必须先调用它再写 body，顺序反了响应体不会被发出，这是新手最常犯的错误之一。POCO_SERVER_MAIN宏负责把main替换成框架的入口，顺带完成 Application 的初始化，用了它就不需要自己写main。

参数说明：setMaxQueued控制的是已完成三次握手但还没被工作线程接走的连接数，超过这个数内核会拒连，它决定了突发流量下你能吸收多少。setMaxThreads是并发处理请求的线程上限，设太大会增加上下文切换，设太小会让请求排队，一般按「平均响应耗时 × 目标 QPS」估一个初值再压测调。setThreadIdleTime让空闲线程回收，避免流量峰值过后线程一直占着。setKeepAliveTimeout决定长连接多久没新请求就关闭，前面的值应该略大于客户端的连接池空闲时间，否则会出现客户端复用连接时正好被服务端关掉的竞态。

跑起来之后，用一条 curl 验证路由，再故意请求一个不存在的路径验证 404 分支：

curl -v http://127.0.0.1:8080/ping # 期望 200 和 JSON curl -i http://127.0.0.1:8080/nope # 期望 404，且响应体由框架生成

两条都符合预期，骨架就可以往上加业务 handler 了。加的时候注意 handler 是无状态共享的——框架每次请求 new 一个新的 handler，但如果你在 handler 里引用了外部单例对象，那些对象必须自己保证线程安全。

4. 文档没写透的构建环节：编译、链接与可选组件的完整配置

中文文档讲 API 讲得多，讲怎么把库接进工程讲得少，而这恰恰是新手卡住时间最长的地方。POCO 是按组件拆成多个动态库的，Foundation、Net、Util、JSON 各是一个，用到哪个链哪个，少链一个就是满屏 undefined reference。这一章把 CMake 接入的两种写法、编译期宏的影响范围、以及链接报错的排查顺序讲清楚，目标是你拿到任何一台干净机器都能在十分钟内把工程编出来。

4.1 用 CMake 接入 POCO 的两种方式

第一种是 CMake 原生方式。如果你的 POCO 是通过包管理器或源码带 CMake 安装的，通常会导出一组形如Poco::Net的目标，可以直接链：

cmake_minimum_required(VERSION 3.16) project(demo CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) find_package(Poco REQUIRED COMPONENTS Foundation Net Util JSON) add_executable(demo main.cpp) target_link_libraries(demo PRIVATE Poco::Net Poco::Util Poco::JSON Poco::Foundation)

逻辑说明：COMPONENTS里列出的组件必须有对应文件，少装一个find_package会直接失败而不是等到链接期。target_link_libraries里不需要重复写Poco::Foundation，CMake 的目标依赖会自动传递，但显式写上有两个好处：一是明确你依赖它，二是某些旧版导出文件里传递依赖不全。

第二种是 pkg-config 方式，适合你的 POCO 是系统包管理器装的老版本、没有导出 CMake 目标的情况：

# 查看当前环境里 POCO 各组件是否都有 .pc 文件 pkg-config --list-all | grep -i poco # 编译：cflags 和 libs 一起给，顺序交给 pkg-config g++ -std=c++17 main.cpp -o demo \ $(pkg-config --cflags --libs PocoNet PocoUtil PocoJSON PocoFoundation)

参数说明：--cflags给出头文件搜索路径，--libs给出-l参数，两个必须都带上。libs 的顺序由 pkg-config 负责，但如果你手动写-lPocoNet -lPocoFoundation，静态链接时顺序错了会报未定义符号，这是 GNU ld 的解析顺序决定的，被依赖的库要放在后面。

选哪种取决于你的工程规模。单文件 demo 用 pkg-config 最快；多目标工程、需要跨平台构建，一定用 CMake 的find_package，因为路径和组件开关都写在构建脚本里，换机器不用改代码。

4.2 编译期宏与组件开关对照表

POCO 的头文件里有一批条件编译宏，会影响 ABI 和类布局。最危险的情况是两个模块编译时宏定义不一致，链接能过，运行时崩溃。常见的几个：

注意：这张表里的宏名以你本地头文件中的实际判断为准，不同版本的开关集合会有增减。判断方法很直接：在头文件目录里搜索这个宏名，看它在#if里控制什么。如果你只用了动态库、也没有特殊平台需求，这四个宏一个都不用定义，让默认值生效是出错概率最低的选择。

还有一个容易被忽视的点：编译标准。POCO 的部分头文件在不同 C++ 标准下会展开不同的实现（比如智能指针相关的兼容层），所以业务代码和 POCO 库本身最好用同一个标准编译。库是用 C++14 编的，你的代码用 C++20，多数情况没事，但一旦涉及std::string_view之类的接口边界，就可能出现链接期找不到符号的情况。

4.3 链接期报错的排查顺序

链接错误看着吓人，其实只有三类，按顺序查基本一次命中。

第一步看符号名，判断缺哪个组件。undefined reference to 'Poco::Net::HTTPServer::HTTPServer(...)'里带Net，说明缺PocoNet；带JSON说明缺PocoJSON；带Util说明缺PocoUtil。这一类占了链接错误的绝大多数，补上对应库就好。

第二步看是不是全都没链接。如果报错里同时出现 Foundation、Net、Util 的符号，那基本是target_link_libraries漏写了，或者 pkg-config 的--libs没生效。这时候不要一个个补，把链接命令打印出来（CMake 加--verbose，g++ 直接看命令行）确认-l参数到底有没有出现。

第三步看 SSL 相关的未定义符号。如果你用了Poco::Net::HTTPSClientSession或任何带 TLS 的东西，除了PocoNetSSL还要链 OpenSSL 的ssl和crypto。报错里会出现SSL_CTX_new这类不属于 POCO 的符号，看到这类符号就该往 OpenSSL 上想，而不是继续加 POCO 的库。同时确认find_package(OpenSSL REQUIRED)找到了正确的版本，混用系统自带的旧 OpenSSL 和自行安装的新版本是这类问题的常见来源。

排查完成后，把最终可用的链接命令固化进构建脚本，并在 CI 里跑一次干净环境的完整构建。这一步看起来多余，但它能挡住「我这台机器能编」这类问题——依赖是隐式传递的时候，换台机器就暴露了。

5. 避坑：中文文档滞后于代码时最容易翻车的五处

中文文档的翻译时间点和代码的演进时间点通常不重合，这不是文档质量的问题，任何翻译文档都有这个时差。真正的风险在于，你会默认文档里写的就是你手上这版库的行为，然后在一个看起来完全正确的示例上卡半天。下面五条都是这类时差导致的典型问题，按「现象 → 原因 → 解决」写，遇到类似症状可以直接对照。

第一条：文档里的类名在头文件里搜不到。现象是按文档写的#include直接报文件不存在，或者编译报某个类未声明。原因是这个类在较新版本里换了头文件路径或命名空间，也有可能是被拆分合并了。解决办法是不要死磕文档里的路径，直接在你的头文件安装目录里搜类名：grep -r "class XXX" /usr/include/Poco之类的命令能立刻告诉你它现在在哪、叫什么。养成「文档查语义，头文件查事实」的习惯。

第二条：示例能编译，运行时报Poco::NotFoundException。现象是打开配置文件、读某个路径时抛异常，路径看起来明明是对的。原因是文档示例里用的是相对路径，而你的进程工作目录和你想的不一样，尤其是通过 systemd 或容器启动时，工作目录往往是/。解决办法是在程序启动时打印一次Poco::Path::current()，把它和你的配置路径拼在一起看，问题立刻现形。生产环境里配置路径应该走绝对路径或者基于可执行文件位置推算，不要依赖工作目录。

第三条：链接报错一大堆，补了库还是报。现象是补上PocoNet之后又冒出PocoUtil的符号，补完PocoUtil又冒出 JSON 的。原因是你可能只看了第一条报错就动手，没意识到链接器是在逐轮报缺。解决办法是从报错列表里把所有不同的命名空间前缀提取出来，一次性补齐。另外注意静态链接顺序，被依赖的库放右边。

第四条：Reactor 回调里读到的数据不完整。现象是短报文一切正常，报文一长就在中间截断，日志里看不出任何异常。原因是把READABLE通知当成了「一次能读完」，回调里只调了一次receiveBytes。解决办法是在回调里循环读，直到返回 0 或抛超时，并把每次读到的数据追加到缓冲区里，等凑够完整报文再交给业务层。这条坑在本地几乎测不出来，因为本机回环的报文通常一次就到齐，只有跨网络分片才暴露。

第五条：日志时间戳差八小时，或者中文变成问号。现象有两个，可能同时出现。时间戳问题是格式化时用了Poco::Timestamp，它输出的是 UTC，而你看日志时按本地时间理解；改成Poco::LocalDateTime即可。中文乱码问题通常出在链路上：源文件编码、日志写入时的编码、查看工具的编码三者不一致。POCO 内部按字节处理字符串，不做编码转换，所以要么全链路统一 UTF-8，要么在写入前显式转换。

5.1 建立自己的「文档降级对照」清单

上面五条只是症状，长期做下去更有效的是维护一份自己的对照清单。做法很简单：每当你在文档和实际代码之间发现一次不一致，就在一个 Markdown 文件里记一行——文档写的什么、实际是什么、你是怎么确认的。坚持两三个月，这份清单会覆盖你项目里 80% 的踩坑场景，新同事进来直接看这一页，比读完整份文档快得多。

另一个技巧是给关键 API 写一层薄封装。比如把日志初始化、配置读取、路径解析各包一层你自己的函数，内部处理时区和编码。这样即使将来 POCO 的行为有变，你只需要改封装层，业务代码不用动。这不是过度设计，而是把「文档可能滞后」这个风险集中到一个地方管理。

6. 把文档当基线做回归验证：三个模块拼一个能跑的小工具

读完文档不等于会用，验证方式只有一个：拿三个互不相干的模块拼一个小工具，让它们的数据流串起来。我一般选配置 + 日志 + JSON 这三样，因为它们覆盖了「启动期读入」「运行期输出」「数据面序列化」三个不同阶段，串起来能暴露大部分集成问题。

具体做法：用Poco::Util::Application做入口，从配置文件读一个端口和一个日志级别；用Poco::Util::LoggingFactory按级别初始化日志通道；再写一个函数把当前进程的关键状态序列化成 JSON 写进日志。这个工具不到一百行，但跑通之后你对 POCO 的初始化顺序、异常传播、字符串编码会有实感。

验证顺序建议按这个来：

最后一步最容易被跳过，但它决定了这个工具在真实环境里的健壮性——配置文件缺失是运维场景里最常见的故障之一，能不能给出可读的错误提示，比功能本身更重要。

一个具体技巧：在Application::initialize里做所有可能抛异常的初始化，并在外层包一个 try/catch，把异常信息写进标准错误后以非零码退出。这样启动失败时，systemctl status或容器日志里能直接看到原因，而不是一个干巴巴的退出码。这个习惯我是在一次线上启动失败排查后养成的，当时进程启动后立刻退出，日志目录还没建好所以什么都没留下，等于一个黑匣子，只能靠猜。

中文文档最大的用处不是让你少写代码，而是让你在遇到问题时知道该去翻哪一章。把文档当基线，每验证一条就记一条，几个月下来这份文档就变成了你自己的笔记。希望帮到你。

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