注意⚠️：修改时一定要修改部署目录下的sql文件。而不是其它什么地方的sql文件

遇到问题：响应数据乱码

乱码特征：ç‹—ä¸ç 这种典型的“拉丁语系”乱码，本质是 UTF-8 字节流被当做 ISO-8859-1 (Latin-1) 解析导致的。

最终定位：**通过 docker logs -f senseeat-app 查看后端日志，发现 MyBatis 查出来的 Row 数据已经是乱码，断定问题不在 Nginx，而在 数据库层数据损坏 或 JDBC 读取解析错误。

原因：由于 MySQL 容器在执行 docker-entrypoint-initdb.d 中的 SQL 脚本时，其 Client 环境可能未对齐 UTF-8。

解决方案：通过在 SQL 文件（01-schema.sql 和 02-dishes_data.sql）的最顶部添加以下代码，强制要求客户端解析器使用 utf8mb4：

在sql前添加的内容如下：

SET NAMES utf8mb4;
SET character_set_client = utf8mb4;
SET character_set_connection = utf8mb4;
SET character_set_results = utf8mb4;

尝试过的方案（排查路径）

在定位过程中，依次排查了以下环节，虽然它们不是本次的“主犯”，但都是确保不乱码的前提：

  • JVM 编码层：在 Dockerfile 启动参数中加入 -Dfile.encoding=UTF-8（确保 Java 内部处理正常）。
ENTRYPOINT ["java", "-Dfile.encoding=UTF-8","-jar", "app.jar"]

  • 应用配置层：查看 application.yml 的 database URL 中是否包含 characterEncoding=UTF-8（确保驱动传输正常）。

  • MySQL 参数层：在 docker-compose 中查看 是否包含--character-set-server=utf8mb4（确保 MySQL 运行参数正常）。

  • 网关转发层：在Nginx配置中设置 的 charset utf-8（确保公网返回头正常）。

以上均未发现问题所在，最终通过查询容器日志，得到后端返回的数据（mybatisPlus日志）显示数据乱码，从而确定插入的数据就乱码，而原sql文件是标准的UTF-8，从而确定是执行sql时服务器环境的问题，故通过sql开头指定编码的形式来解决该问题。