你对脚手架有什么样的需求呢？ 或者说需要什么功能呢？

我自己是不用脚手架的，gin 对我来说已经很开箱即用了，每次新起东西因为写的很习惯，烂熟于心，所以就从来不在这里面用脚手架，不过我猜也许还是有些需求？

不知道你需要的是什么样的，是不是那种有基础目录结构，router api service dao model 分好，还搭了 gorm ，以及队列，kv 库等都装好了的那种？

我的孩子才 3 岁多，我平时通勤时间长，陪她很少。

她的年龄也还小，那些电子游戏，再简单的，对她来说都比较难上手，她无法理解按键与动作行为的关系。

她看不懂我玩的守望先锋，但她知道我很开心，会粘着我旁边自己玩自己的。

也不妨碍她看我玩马里奥，俄罗斯方块，昨天抱着她，让她指挥，她看我玩了 30 分钟植物大战僵尸。

那 30 分钟她笑得像朵花。

上床睡觉还讲了半天樱桃炸弹，土豆，向日葵，她自己编了一个打僵尸保护家园的故事。

所以你看，是不是电子屏幕，是不是玩游戏，根本没那么重要。

重要的是陪伴，是花的时间与心思。



等她长大了，十来岁的时候，我想让她带我打，那时候我老了，反应速度不够了，自己打游戏肯定打不过别人，要有一个反应快的带我。

就怕她沉迷于现实社交顾不上我这个老头子了哈哈哈哈哈。

其实这个世界上不是只有微服务和单体两种模式的……
很多公司，包括我个人的项目其实往往是若干个小服务，数量可控，好管理，又能取到尽可能多的优点……

@javak 但你要看身边国内的求职现状，Java 就是一个人人喊打人人用，事实标准的玩意儿。
没有人喜欢它。
但找工作都要它。

比起组件库，我更想问一下，react 下基于某个组件库形成的后台管理框架的选择有哪些？

比如 vue-admin-template 使用 element 之于 vue ，或者 pro ant design 使用 antd 之于 react ，但我不知道是国外用户的使用习惯原因还是什么，我感觉这种打包好的“后台管理框架”，在 react 生态下我总是感觉不够多。

虽然打包起来的东西也没几样，一些 theme config ，全局 user store ， 经典的路由，权限封装，request 封装，api proxy ，其实也就那几样。 但我感觉我找 vue 下的类似东西的时候总是选择更多一些（好坏不谈）。

很好，不用啥都塞 redis 了。

@dangyuluo 我记得没错的话，信息啊熵的程度的不同，确实会影响物体的质量变化。

多大内存，我记得默认很卡吧。。。

Python 太灵活是真的，但拜托你们也把文档读完啊……

这工具对我可能意义不大，但我还是要感谢下楼主，你可能给了我一个新思路。

我也算是重度的 bookmark 使用者，一直以来有个困扰，就我并不喜欢很混乱的书签栏，有的时候我会不小心收藏很多重复的东西。
但我又浏览的速度很快，会大量添加，为了保持一定程度的整洁，我会逼着自己花费大量时间去整理。
而且我发现数据量大的时候，我的设备数量又多，有的时候会出现 sync 之后冲突或者重复，还有回退的问题，整理了一次还要再整理一次。

反正不胜其烦。

今天看到你说你有几万条，我突然想到，bookmarks 本身就是个数据库而已。只要机器性能够，我往里面随便扔又能怎样。
反正现在才几百条的时候，我已经很重度的依赖搜索功能了，到了几万条又怎样，估计还是搜索。
那不如放弃整理，或者准确点说，放弃那种强迫症一样的整理，想开点，扔个几千几万条又怎样。
我不想天天整理书签了。

我不觉得 redis 在这种场景下有任何麻烦和浪费。

我还以为是那个 app 『不背单词』

不过讲实话那玩意儿还挺好用。

就是我司啊。

有一些历史项目 PHP 的，要维护，工作量很小。
一些新项目和计划中的会重用 Python 和 Go 。

但在我们这小地方按语言来找开发，不好找。 如果我招聘的时候顶着名头是 Python 和 Go，一个结果是来一堆培训班出来写爬虫的，一个是根本找不到人。

还是 PHP 和 Java 多。

但如果我只以『服务端开发工程师』的名义来写招聘，里面写明语言要求，很多人标题看都不看也不来。他们以为我是个什么都不懂的 HR 。

如果以招 PHP 或者 Java 的由头来找，会有大把的人可以看得到。 我会在面试过程中讲明接下来涉及的语言种类，业务需求，看对方愿不愿意。

别说，有用的多。固然有的人是一年经验用十年，往死了认准一门语言打算用到死，但也有一些人，虽然以前写个 PHP，自己多少也接触了些 Node 啊 Python 啊，应用领域也许窄一些，但对运行原理，系统架构方面有思考。

我只要在这个面试过程中讲明白了，和对方开诚布公的聊一聊，其实往往对方不光不会介意，甚至会跃跃欲试。

说到底，还是要在一个合适的节点把话说开了。

我四室都觉得不够。

相信我，你想多了。

尤其是，家里不要做什么工作室。信我。

还有我有个习惯就是，老旧项目会尝试在动结构之前，把包依赖在可以的情况下升级版本…… 优先级比动代码本身高。
有的时候是换了就不能跑，但也得折腾。
这事很重要。
升级到新版本，你才有足够好用的工具来继续往下折腾。

尽可能选兼容性高的方案来升级，让自己可进可退。

不管你觉得动手多难，其实按我动屎山的经验，交叉关联再多的东西，总归可以从一个函数来起，逐步迁移，小范围折腾。 务必保证每次修改的原子性（这里的原子指的是尽可能的影响小，越小越好），然后修改个半个月下来，其实发现也还好。

但小伙子你听我一言。对这种前端项目，你第一个要动的可能不是上手动已有组件。而是去看看 package.json 里引用的第三方包，是不是有些有坑。最好逐个去看完，一些可以从外部依赖改成放到本地 vendor 的，就放到本地。

安内必先攘外。

对外部第三方的组件和模块引用，不把它摸个门清，你后面会发现左右为难，有的动也不是不动也不是。

新开发的时候大量依赖外部组件是个多快好省的方法，但时候差不多的话，就得把它本地化，改成自己的。然后你才能放心的去愚公移屎……

不行。

Vue3 自己没问题。

周边生态没跟上。

说明里面调用了浏览器……被 macOS 自己检测到了……