## 功能概述 完整实现了ljwx-admin的自定义logo功能,支持部署时动态替换客户logo,无需重新构建镜像。 ## 实现内容 ### 1. 自定义logo脚本 (client-deployment/customize-admin-logo.sh) - 支持PNG、JPG、JPEG、SVG格式的logo文件 - 自动检测custom-assets/目录中的logo文件 - 支持多种命名规范:logo.xxx 或 *logo*.xxx - 动态注入logo配置到前端应用 - 实时生效,无需重启容器 ### 2. 前端logo组件增强 (ljwx-admin/src/components/common/system-logo.vue) - 支持部署时注入的logo配置(优先级最高) - 兼容原有API方式的logo获取 - 支持动态logo配置更新事件 - 优雅降级:logo加载失败时自动使用默认logo ### 3. 部署脚本集成 (client-deployment/deploy-client.sh) - 自动检测VITE_CUSTOM_LOGO配置 - 在服务启动后自动应用自定义logo - 完整的状态反馈和错误处理 ### 4. 配置文件支持 (client-deployment/custom-config.env) - VITE_CUSTOM_LOGO=true 启用自定义logo功能 - 完整的配置文档和示例 ### 5. 使用文档 (client-deployment/custom-assets/README.md) - 详细的logo文件要求和命名规范 - 完整的使用方法和故障排除指南 - 推荐的文件格式和尺寸要求 ## 技术特点 ### 灵活的Logo支持 - **多格式支持**: PNG、JPG、JPEG、SVG - **智能识别**: 支持logo.xxx或包含logo的任意文件名 - **尺寸适配**: 自动适配不同尺寸的logo文件 - **透明背景**: 完美支持PNG和SVG的透明背景 ### 部署时动态配置 - **无需重构**: 部署时动态注入,不需要重新构建镜像 - **即时生效**: 配置完成后立即生效,支持热更新 - **配置注入**: 通过JavaScript全局配置实现动态logo - **缓存刷新**: 自动添加时间戳防止浏览器缓存 ### 完善的错误处理 - **优雅降级**: logo文件不存在时自动使用默认logo - **多重检测**: 部署配置 → API配置 → 默认logo的优先级 - **详细日志**: 完整的调试信息和状态反馈 ## 使用方法 ### 客户部署步骤 1. 将logo文件放入 `client-deployment/custom-assets/` 目录 2. 在 `custom-config.env` 中设置 `VITE_CUSTOM_LOGO=true` 3. 运行部署脚本: `./deploy-client.sh` 4. 访问管理端查看自定义logo效果 ### 支持的logo文件 ``` custom-assets/ ├── logo.png ✅ 推荐格式 ├── logo.svg ✅ 矢量格式 ├── company-logo.jpg ✅ 包含logo关键字 └── brand-logo.png ✅ 自定义命名 ``` ### 验证方法 - 部署完成后访问: `http://SERVER_IP:8088` - 检查侧边栏和页面标题处的logo显示 - 浏览器控制台查看logo加载日志 ## 向后兼容性 - 完全兼容现有的API方式logo配置 - 不影响未启用自定义logo的部署 - 保持原有logo组件的所有功能 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
4.0 KiB
4.0 KiB
MySQL数据库修复与重建指南
问题背景
在LJWX系统部署过程中,遇到了ljwx-mysql Docker镜像数据不完整的问题,导致应用启动时出现"Table 'lj-06.sys_org_closure' doesn't exist"等错误。
问题分析
根本原因
- 数据导出不完整: 原始data.sql文件只包含最小化的test_table测试数据,缺少完整的应用表结构
- 数据库名称映射: 导出的完整数据库名称为
lj-06,而不是test - Docker镜像缓存: 即使更新了data.sql文件,Docker镜像可能仍使用旧的缓存层
影响表现
- 应用启动时报告缺少关键表:
sys_org_closure、sys_org_units、sys_org_manager_cache等 - MySQL容器能正常启动,但数据库内容不完整
- 前端页面无法正常加载组织架构相关功能
修复步骤
1. 导出完整数据库
# 从本地MySQL实例导出完整的lj-06数据库
mysqldump -h 127.0.0.1 -P 3306 -u root -p123456 \
--single-transaction \
--routines \
--triggers \
--complete-insert \
--databases lj-06 > data.sql
关键参数说明:
--single-transaction: 保证数据一致性--routines: 导出存储过程和函数--triggers: 导出触发器--complete-insert: 生成完整的INSERT语句--databases lj-06: 指定数据库名称
2. 清理旧的容器和卷
# 停止并删除现有容器
docker stop ljwx-mysql && docker rm ljwx-mysql
# 删除旧的数据卷
docker volume rm client-deployment_mysql_data
3. 重建MySQL镜像
# 使用--no-cache强制重建,确保使用新的data.sql
PUSH_TO_REGISTRY=false LOCAL_BUILD=true PLATFORMS=linux/amd64 ./build-and-push.sh mysql --no-cache
4. 启动并验证
# 启动新的MySQL服务
cd client-deployment && docker-compose up -d ljwx-mysql
# 等待MySQL完成初始化(约30秒)
sleep 30
# 验证数据库和表结构
docker exec ljwx-mysql mysql -u root -p123456 -e "SHOW DATABASES;"
docker exec ljwx-mysql mysql -u root -p123456 -e "USE \`lj-06\`; SHOW TABLES LIKE '%sys_org%';"
验证结果
修复完成后,MySQL容器应包含以下数据库结构:
数据库列表
Database
information_schema
lj-06 # 完整的应用数据库
mysql
performance_schema
sys
关键表验证
USE `lj-06`;
SHOW TABLES LIKE '%sys_org%';
-- 应返回:
-- sys_org_closure
-- sys_org_manager_cache
-- sys_org_units
配置说明
MySQL 8.0配置 (my.cnf)
[mysqld]
# 基础配置
default_authentication_plugin=mysql_native_password
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO
# 字符集配置
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci
Docker构建配置
FROM mysql:8.0
COPY data.sql /docker-entrypoint-initdb.d/01-init-data.sql
COPY docker/mysql/my.cnf /etc/mysql/conf.d/ljwx.cnf
注意事项
- 数据库名称: 应用连接的数据库名称是
lj-06,不是test - 密码配置: 默认root密码为
123456 - 初始化时间: MySQL初始化需要30秒左右,大数据量情况下可能更长
- 版本选择: 使用MySQL 8.0,比MySQL 9.0更稳定且兼容性更好
故障排除
如果仍然缺少表
- 检查data.sql文件大小(应该是15MB+,而不是几KB)
- 确认Docker镜像是否真正重建(使用--no-cache参数)
- 检查MySQL初始化日志:
docker logs ljwx-mysql
如果数据库连接失败
- 检查密码配置(默认123456)
- 检查数据库名称(lj-06 vs test)
- 确认MySQL服务完全启动
总结
此次修复的核心是确保:
- 数据完整性: 导出包含所有表、存储过程、触发器的完整数据库
- 容器重建: 清理缓存,强制使用新的数据文件重建镜像
- 配置正确性: 使用稳定的MySQL 8.0版本和正确的配置参数
修复后的ljwx-mysql镜像包含了完整的lj-06数据库,能够支持LJWX系统的所有功能模块正常运行。