前言

Fcircle，无需担忧友链太多无暇一个一个访问，可以帮你快速整理出好友们新发的文章，如果你和我一样是一名站长，那么可以尝试部署一下这个项目：Github官方仓库

踩坑

这次就简单记录一下部署遇到的坑吧
其实部署难度并不高，只需要部署一下后端，并且文档教程很详细（仅限于默认部署的方式)

先简单说一下hexo-circle-of-friends这个项目的原理吧，其实很简单，主要分为前后端，前端主要由Hexo的主题负责，如果主题不支持也可以通过安装插件的方式解决，具体安装方式可以参考各主题的文档，如果是插件安装可以去店长的博客观看详细教程

至于后端，我将其分为了三部分，爬虫、数据库、API接口
整个原理很简单，爬虫定期爬取友链文章并存入数据库，当前端访问API接口时，会访问数据库查询最新发布的文章返回给前端

官方文档中提供了3x4共12种部署方式

server和docker的部署方式总的来说大同小异，都是本地部署并且本地提供了API接口，只需要放行对应端口即可，而Github部署的话还需要Vercel部署一个API接口
我觉得绝大多数站长都是通过Github+Sqlite部署的，Github部署的原理是通过定时任务触发Github Action任务然后爬虫爬取友链，然后存储在Sqlite中再git commit更新到仓库中，Vervel发现仓库更新了就会重新部署，读取数据库中的内容等待前端调用
这么做确实是挺不错的，但是由于Sqlite数据库的更新会不断提交新的Commit，再加上Git的机制，并不会清除原本的数据库，会占用额外的Github资源，况且用Git仓库做Sqlite数据库这种方式本身并不优雅，于是我就想采用Github+MongoDB的部署方式
原理和之前差不多，都是通过定时任务触发Github Action然后爬取友链的文章，然后会直接存储在MongoDB中，Vercel也不需要每爬虫一次就重新部署一次，会实时访问MongoDB获取数据
根据文档的教程，设置好对应的环境变量手动触发一次Github Action，所有地方都正常，唯独MongoDB中没有获取到数据，自然访问搭建在Vercel上的API也不会有任何数据，一开始我以为环境变量写错了，就查看Github Action的工作流，发现确实是进入到了MongoDB的Update Post的步骤中，并且整个Github Action也没有任何报错，我也找遍了全网没找到解决方案，我也看了源代码，确认了不是MONGODB_URI的格式问题，就这么折腾了5个小时，不停的尝试，将Storage_Tpye更改为sqlite就一切正常，改成mongodb什么都正常就是数据获取不到数据

解决问题

最后只能从源码入手了，先看Github Action的任务执行流程，其实很简单，根据Storage_Tpye的类型传入对应的环境变量执行main.py，然后我在Github Action的日志中发现，虽然我进入了mongodb的分支但是logging模块传出的居然是sqlite的pipline，然后我就去找他是怎么选择的进入哪种存储的pipline的，最后发现是在fc-settings.yaml的下面有个运行方式和存储模式的选择，默认分别是github和sqlite

找了5个小时，搜索朋友圈的搭建方法、重开数据库、重设访问用户、重设访问IP、新开MongoDB账户，查看源码，终于找到问题所在了

最后想想其实就是多部署方式惹的锅，Server和Docker的部署方式完全依赖fc-settings.yaml的配置，但是由于Github不能将fork的仓库设为私有，如果在Github仓库上直接配置fc-settings.yaml由于暴露数据库账号密码的风险，所有使用的Github的Action的环境变量，虽然Action是判断了存储方式并传递了环境变量，但是运行main.py后，程序由以fc-settings.yaml的配置为主，导致使用了默认sqlite的pipline所有没有向MongoDB写入数据，但是由于之前Github Action根据环境变量Storage_Tpye只传入了MongoDB相关的环境变量，Github Action也没有提交db.sql的权限，所以就成了除了运行了一次Github Action其余事情什么都没发生

尾声

希望hexo-circle-of-friends的大佬可以修改一下运行逻辑，改成优先级为：命令行 > 环境变量 > 配置文件的运行逻辑是否更好

如果你也遇到了类似的困难，希望文章对你有帮助