常见问题

常见问题（FAQ）¶

某些 css 文件不生效¶

先确认样式文件已正确加载、选择器优先级没有被覆盖、目标元素确实具有对应的类名。可在浏览器开发者工具的 Elements/Styles 面板中检查规则是否匹配。

reactstrap 样式不生效¶

确认已引入与当前 Bootstrap/Reactstrap 版本匹配的 Bootstrap CSS 文件；组件库本身不一定会自动导入样式。

静态资源引用路径¶

静态资源应按构建工具的规则引用，并确认构建产物中包含这些资源。字体图标尤其要检查字体文件 URL、部署基础路径和服务器 MIME 类型。不要仅凭开发环境能显示就判断生产环境路径正确。

清理未使用的依赖¶

可以使用 depcheck 等工具辅助识别未使用依赖，但工具结果需要人工核对，动态导入和构建配置中的依赖可能被误报。

reference:

升级 ESLint 后出现解析错误¶

这是一条历史排查记录。升级 ESLint 后若出现解析错误，应先核对 ESLint、配置文件格式及解析器的兼容版本，再按当前 ESLint 配置方式迁移。

https://stackoverflow.com/questions/70386909/problem-with-babel-eslint-parsing-error-require-of-es-module

自动生成 eslint 配置文件¶

npm init @eslint/config

参考 https://www.npmjs.com/package/eslint#installation-and-usage

服务端无法连接数据库¶

Access denied for user 'root'@'172.18.0.1' (using password: YES)

Access denied 通常表示用户名、密码或授权主机不匹配，而不是数据库未启动。请检查连接配置、用户授权以及容器中实际使用的凭据；若是连接超时或拒绝连接，再检查数据库服务和网络配置。

服务器无法运行¶

先检查 Node.js 版本是否满足项目要求、启动命令和错误堆栈。只有运行时不支持所用语法或模块格式时，才需要配置转译；通常不应默认将服务端代码编译为 ES5。

请求跨域¶

前后端使用不同源（协议、主机或端口不同）时，浏览器会执行 CORS 检查。应在服务端仅允许所需的来源、方法和请求头；使用凭据时不能将 Access-Control-Allow-Origin 设置为 *。

const cors = require("cors");

app.use(cors({
  origin: "https://your-frontend.example", // 替换为实际前端来源
  methods: ["DELETE", "PUT", "POST", "GET"],
  allowedHeaders: ["Content-Type", "Authorization"],
  // 如需 Cookie 等凭据，再启用 credentials，并在客户端配套配置。
  credentials: false,
}));

发送请求时，数据库报错¶

错误日志

/novel-reader/node_modules/mysql/lib/protocol/Parser.js:437
throw err; // Rethrow non-MySQL errors
Error: Cannot set headers after they are sent to the client at new NodeError (node:internal/errors:393:5)

该错误通常表示同一个请求处理流程尝试发送多个响应。每次 res.send()、res.json() 或 res.end() 后，应确保当前分支及时 return，并检查异步回调是否重复响应。

参考：https://blog.csdn.net/qq_48009509/article/details/121625588

更新 ejs 大版本的问题¶

历史排查记录：升级 EJS 主版本后应检查迁移说明和模板语法。依赖升级不一定是问题根因，应根据实际错误定位。

解决：参考报错信息，使用 EJS-Lint 工具检查格式错误，全局安装后，执行

ejslint ./src/views/*.ejs

会提示具体的错误位置，稍后手动修改 include 语法，即可正常运行

- <%- include style %>
+ <%- include('style') %>

参考

https://www.npmjs.com/package/ejs

https://github.com/RyanZim/EJS-Lint

token 在不同页面传参校验¶

不要将认证 token 放在 URL 查询参数中，因为 URL 可能进入浏览器历史、访问日志和 Referer。应使用项目当前设计的安全凭据传递方式，并设置有效期、服务端校验和适当的 Cookie 安全属性。

数据库端口号冲突¶

MySQL 默认端口为 3306。如果本机已有服务占用该端口，容器端口映射可能冲突；可为其中一个服务配置不同的宿主机端口。多个 MySQL 实例可以在不同端口同时运行。

实际环境中不可能有两个 mysql 在不同的端口跑。所以可以本地只开发一个项目，或者临时改一下数据库的端口号等。

数据库存储小说会不会太长¶

MySQL 的 LONGTEXT 可存储较大的文本，但实际可存储和传输的大小还受数据库配置（如 max_allowed_packet）、驱动、应用服务器和内存等限制。应按实际限制设置文件大小上限并进行测试。

列表查询可只返回标题等摘要字段，避免传输完整正文；这样通常可以减少网络开销和不必要的数据处理。

上传时应校验文件类型和大小并返回明确错误。若文件较大或需要独立管理，可考虑对象存储或文件存储，并在数据库中保存元数据和引用地址。

数据库分页查找¶

如果想加载某个章节的数据，能否从 longtext 字段中返回指定的字符串，不需要一次性返回全部的页面

数据的创建时间¶

数据库执行增加操作时，通常需要 create_time 字段。这个字段可以在三个场景生成：

1、前端发出请求时，使用 new Date() 获取客户端发出请求的时间（不建议使用，也不利于网络请求）

2、后端接收到请求时，使用服务器的时间，例如 Django 或者 nodejs 的时间。

# python 内置函数
from datetime import datetime
current_time = datetime.now()

# django 内置函数
from django.utils import timezone
current_time = timezone.now()

// nodejs 内置函数
let current_time = new Date();

3、数据库执行操作时，使用 NOW() 函数生成写入数据的时间

建议统一时区策略（通常在服务端和数据库中使用 UTC，并在展示时转换）。使用数据库默认时间或服务端时间都可以，但应避免同一业务中混用不一致的时区。

多机部署时也应统一时间同步和时区策略。仅将所有机器设置为东八区并不能保证时钟同步。

两个表是否进行关联的分析¶

在其他案例中，员工表和部门表实现了外键关联，因为这个功能是强相关的。员工必须选择一个部门，删除部门时，或者删除员工时，必须同步更新另一个表。

其他项目中，用户和评论的关系是一对多的关系，但是在 MYSQL 中并没有进行外键约束。因为这个评论和用户不属于核心业务，删除用户时也不会删除对应的评论。这个场景就使用了单表操作。

当前阅读器项目中，用户和评论的关系，也是一对多的关系，目前选择使用外键进行约束，主要作为练习。

结论：两个表是否进行关联，需要看业务场景，如果更新一个数据，需要对另一个数据进行强关联，那么就使用外键约束，否则单表也可以完成任务。

ClientClosedError: The client is closed¶

出现 ClientClosedError: The client is closed 时，可能是客户端尚未连接、已断开连接，或连接生命周期管理不正确；也应核对代码使用的 API 与安装的 Redis 客户端主版本是否匹配。

历史方案：将客户端降级到旧版本可以恢复与旧代码的兼容，但不应在没有安全和维护评估的情况下固定使用旧依赖。

npm install --save redis@3.1.2

解决方案 2：使用 redis 4 的语法

https://www.npmjs.com/package/redis

import { createClient } from "redis";

const client = await createClient()
  .on("error", (err) => console.log("Redis Client Error", err))
  .connect();

await client.set("key", "value");
const value = await client.get("key");
await client.disconnect();