偶然刷到这篇博文：我在字节跳动实习的三个月 | 无辄的栈 ，感慨良多。想来毕业开始搬砖至今也有三个月，好久未更新 blog，还是写写吧~ 兜兜转转，可以让自己慢下来思考的，还是博客的编辑器。
最近主要在看 React 和 Redux 还有各种状态管理相关的东西，基本熟悉了 redux, redux-saga 的套路，但对于它们背后的原理与设计思想等东西，则没太多涉及。当然，学习这事儿并不着急，过去对认知与学习的本质小有研究，信息搜集到内化的过程基本都没什么障碍。也越发相信一点，无论什么东西，能否学会只是时间问题。
然而，工作日完全投入工作、周末只想躺尸的日常，留给自己探索的时间并不多。寄予厚望的假期，并没有想象中的产出，让人有点力不从心。对那篇“辩证看待996”，只想呵呵。
在国内互联网糙快猛的浮躁节奏下，如何平衡出自己探索与追求极致的空间，的确是个值得思考的问题。某些瞬间有想过，是否应该放弃，退居二线、让自己轻松一些。
放弃是不可能放弃的，我等凡夫俗子，互联网的薪资暂时还无法拒绝，也就只好在六便士与月亮之间徘徊啦~
想到这点，也释然了。
周三没有加班，走之前去了下洗手间，对着镜子看看自己，还有脖子上挂着的工牌。由于工作需要接触各种各样的广告宣传的关系，想到了各种各样的“标签”，诸如清华北大、211、985、xx资格/等级证书、获得xx奖等等。
一直以来我对“标签”这玩意儿并不怎么感冒，但挂着公仔厂的工牌，无论是租房找室友、坐车、买东西等等，似乎总很快能给人带来某种天然的信任感；买东西的时候，常常倾向于选择某个品牌而懒得去挑。不可否认的是，每一个人心力有限的背景下，标签降低了认识与建立信任的成本。
上篇文章 我们写了 Flarum 二次开发项目的规划，这里也分享一下本地开发与调试 Flarum 的配置的方案，助你快速搭起 Flarum 的本地开发调试环境。
关键软件：
Windows 下的额外配置：
上篇文 我们介绍了适用 Flarum 的 Docker LNMP 环境的配置，本文将进一步从本地环境搭建、版本控制的设计的角度，介绍一套可操作的 Flarum 项目配置与二次开发迭代方案。
目前本文方案在 0xFFFF 社区 运行良好，它遵循了现有的 Composer 加载，版本管理的机制，可以跟踪本地的修改、随时切换官方分支或定制开发的分支，避免那些诸如定制修改丢失、与最新版本代码难以同步等问题。若你想用 Flarum 搭建论坛并想对它进行二次开发调整，不妨试试本文方案。
本文方案的前置技能要求：
注：本文基于当前最新的 Beta 13 版本 展开，列出的脚本与命令，需要在 Unix 命令行环境运行（Linux 或 macOS，Windows 最好安装 WSL 以及 Docker）。
Flarum 是一个简洁的轻论坛程序，交互体验做的十分不错，也有良好的插件扩展机制。接触过的人可能知道，它目前还在 beta，在功能更新和迭代方面不算稳定，部署、修改与定制功能更是一件麻烦的事情。
在 2018 年，我基于它构建了 0xFFFF 社区。经过两年的不断推翻与修改，慢慢沉淀下了一套适合持续迭代的 Flarum 部署与开发迭代方案。
这里主要介绍 Flarum 在服务器和本地开发环境的部署方案。本文假定读者对 Linux 命令行操作、Docker 与 Docker Compose 有基本的了解。相关文件均已开源在 GitHub: zgq354/flarum-docker-env。
在 Linux 折腾 LAMP/LNMP 的同学可能经常被各种环境配置的细节问题折磨，诸如 Nginx 配置、“伪静态”（URL Rewrite）、各种文件权限、所有者问题等等。好不容易配置好了，过一两个月可能已经完全忘记，在未来需要修改或更新之时，如西西弗斯受罚一般，重重复复做着相似的事。
基于 Docker，只需要一系列配置文件，就可以从各种各样的针对手动配置解放出来，通过 Git 管理配置的历史版本。可以随时切换环境配置，而不担心因时间的流逝忘记当初是怎么搞的。
接下来会介绍这个方案的细节，若只想把项目跑起来，可以直接跳到本文的 “使用” 小节。