• 修复 查询文档列表失败的问题：https://stackoverflow.com/questions/34115174/error-related-to-only-full-group-by-when-executing-a-query-in-mysql
• 导航栏标识大小写导致选中的时候无法高亮的问题
• 修复上一版本增加虚拟目录导致的 sitemap 找不到的问题
• 面包屑导航链接不正确的问题
• 文档上传过程中临时文件命名出现重名的问题
• 是否允许上传重复文档（管理后台 -> 系统设置 进行设置）
• 每天凌晨 2:00 自动更新站点地图(sitemap)

• Gitee:
• Github: https://github.com/TruthHun/DocHub

下载地址

https://www.bookstack.cn/books/dochub

演示站点

文库之家：

DocHub 项目之所以在码云和GitHub收到的star比较高，那是因为项目切中了大多人的需求，以及前端页面设计的比较简洁好看，且用户体验也尚可。

但真实情况却是代码写的很渣，这个真不是自谦。尽管我已经尽了很大努力去优化，但是一个不合理的数据库设计以及不规范的代码写作，导致了后续功能扩展和代码维护困难重重。

所以，还是决定对项目全部推翻了进行重构。现有分支仍会持续维护和修复Bug，但不会再增加新功能。重构会在新分支上进行，对于不兼容问题，届时会出一个迁移工具，以帮助从旧版迁移到重构的新版本上来。

高清图看这里： https://www.processon.com/view/link/5b29103ae4b0d4a19d7c67f1

1. DocHub 将采用前后端完全分离的技术方案，一套API接口，供PC前端和移动端APP和小程序使用
2. 文档转换服务是比较耗费服务器资源的，属于计算密集型，该功能将独立成一个文档转换服务moredoc（也就是魔刀），以便可以独立部署到另外的服务器上
3. CloudStore是一个云存储服务中介，支持将文档等文件数据存储到各大云存储上。

moredoc（魔刀文档转换服务）

高清图看这里：

moredoc的技术构成和转换原理，如上图所示。

该服务将支持全部 office 文档类型和epub等文档类型转为可在前端页面展示的图片以提供用户阅读。

现有dochub文库系统目前文档转换依赖的软件基本上就是上面这些了（除了）。

前端技术方案主要用Vue，考虑到的需要，配合Nuxt使用，UI 使用ElementUI。

移动端使用uni-app的解决方案，一次开发，多端分发。

后端选用Go语言，至于群友问为什么不用PHP和…

我也是做过三年PHP开发的，好不容易跳脱出来，又想骗我回去，怎么可能…Python的话，在公司也就写写脚本做做运维，并没用真正实现过一个产品的开发，对这门语言还是不熟练。

所以综合考虑选用Go语言，Go语法简洁，性能和开发效率都很高，编译成二进制可执行文件之后，直接丢到服务器就能跑了，还不需要安装环境依赖，部署简单。

重构周期

我想按照自己的节奏来开发，由于是业余时间做的开发，所以开发周期至少要半年以上。