不建议把这些功能全塞到 Go 技术栈里，Go 的生态决定它比较适合做微服务(你去看前几名的框架，一水的轻量级)，也就是 API CRUD 的那一部分；这方面更像 Flask，而 Django 是大而全的。

大而全的框架现在比较少见了； Node.js 下的 Egg(KPI 预警)、Express 也集成了不少东西，你自己开发的话前后端都用 JS/TS，也比较方便。

个人开发也可以前后端分离，只要做了分离，以后扩展就非常方便。比如前期可以直接在 Go 里挂个静态路由给前端目录，后续可以换 Nginx，性能不够上集群，最终可以迁移到 CDN 。

SEO 的话可以去参考一些 SSR 方案，也就是说在服务器上把 Vue 、React 之类的富前端页面进行静态化渲染，专门用于 SEO，因为静态化了，所以这块也可以和原本的前端文件一样的方式提供。

如果你对 Django 很熟悉，也觉得 Django 满足当前的需求，那么就用 Django 吧，没必要非要换技术栈，因为不同技术栈的设计目标、特性都不同，所以你没法简单把一个模式从一个技术栈搬到另一个技术栈，那样最终的结果很可能是你觉得还是不如原来的技术栈好用；要想学习多些领域，就得打破思维定式，去看看真正适合每个技术栈的方案都是什么。

不懂后端的写后端代码，可能会写出不那么好的代码。
不懂前端的写前端代码，也可能会写出不那么好的代码。

愿意跳出舒适圈去学其他领域，挺好的。

如果是技术交流的话可以把源码发出来。

如果是产品推广的话，还涉及到一些其他问题：
1. 跟其他产品比起来有啥亮点？
2. 如何确保安全？

另外作为一个全栈开发，想给的建议是多了解服务器、中间件、数据库、后端系统架构思想、安全，毕竟语言、引擎、框架只是后端的九牛一毛。

可以自己买便携装的那种可溶水的一次性的马桶垫，有的牌子设计还比较合理，用习惯了也不觉得麻烦，像纸巾一样随声带几片就好。

一些需要国际化的场所可能要考虑除了亚洲人和斯拉夫人以外，大部分人都没法用蹲便，既然本地人也都能用马桶，本着建造和维护成本的考虑，可能也就决定统一用马桶了。

公共厕所本来就是卫生很差的环境，怎么搞都改变不了本质的，所以还是得靠自己。

如果内存够用的话也没啥问题吧。

感觉可能痛点在于打开重复的页面？
可以试试一些自动关闭重复页面的扩展，比如 Chrome 下的 Unique Tabs 或者 Firefox 下的 Duplicate Tabs Closer 。

看 parted 的手册，
https://www.gnu.org/software/parted/manual/parted.html
2.4.14 小结表明进率用的 1000，如果是 1024 应该用 GiB 单位（但这个貌似也没有统一）。

fdisk 、parted 看的是分区大小，df 看的是文件系统大小，分区里除了文件系统以外还需要额外的空间来存放其他必要信息，所以实际分区会比文件系统更大。

（这段可能需要求证）如果不是磁盘上最前面的分区的话，fdisk 可能会小于 parted，因为 fdisk 是比较精确的，会从分区实际开始的地方算，而 parted 可能是从前一个分区结束的地方开始算，但实际上分区只能以扇区为最小单位，如果前一个分区的结束位置在扇区中间，那么扇区剩下的部分是无法被后面的分区利用的，也就是说后面分区实际的起点是下一个扇区的开头。

所以引导分区做为第一个分区，的空间计算比较明确了，512*1024*1024/1000/1000≈537 。

至于用 df 的数反推分区空间，这个可能跟各个文件系统的标准有关吧，通常没有这种需求，所以也不知道怎么算。

喜欢，但是也看个人口味状态，一个人不会一直喜欢吃一种东西，也不会一直不喜欢吃一种东西。

对于有些地区的饮食习惯来说，腐乳是可以当咸菜吃的，比如白粥，天津人喜欢吃腐乳喜欢到可以直接包在饺子里。

苦瓜通常都是开水焯一下，然后凉拌，我有时候状态好就越吃越爽口，有时候状态不好就不想吃，另外苦瓜摊鸡蛋可以大幅削弱苦味，不喜欢苦味的人可以试试。

皮蛋本身有品质好坏，有的好吃也有的确实不好吃，腌制皮蛋是个技术活，腌料有时候多一点点少一点点最终都会导致皮蛋很不好吃。
如果是好吃的皮蛋，拌豆腐应该会很好吃，做皮蛋粥也会很香。当然每个人味觉不一样，有的人天生会对某种食物有特殊的味觉，就像有人难以接受香菜，也有人非常抗拒鱼腥。

需求是希望收到的所有请求之间按照顺序一个一个执行是吧？

可以用消息队列的思想，就是来请求会异步插入到一个队列里，然后单线程一个一个地消费。

最简陋的做法是在一个 module 的根作用域下声明一个 Array，然后每次来请求都 unshift 一个消息，服务里单独跑一个循环去从数组里 pop 消息出来处理，处理完再 pop 下一个。

有分布式需求的话就用 Redis 、RabbitMQ 之类的消息队列中间件，可以启动一个集群服务作为生产者往队列里插消息，然后启动一个消费者服务来同步一条条消费。

npm 自己其实也是被当做一个包放在全局的 node_modules 下的，你可以把新版的 npm 覆盖过去。

另外一直在 MacOS 和 Linux 下用 nvm：
nvm install 新版本号 --reinstall-packages-from=旧版本号
可以做到连着全局包一起迁移过去。
几年前尝试过在 Windows 上用 nvm 无果，nvm 本身实际是个 Shell 脚本，原版不能在 Windows 上用，有个 nvm-windows，不知道现在是否好用。

市面上很多应用是为了商业化才变重的；铁了心不想赚钱的话，怎么开发都可以，也不需要听别人怎么说，满足你自己的需求是首要的。

没有或者可以无视精度损失的问题的话，我也是用浏览器 console 或者在 terminal 里直接启动 Node\Python\JShell(Java)\expr(Shell)来算。

正好拿着手机的话就用手机的计算器。

@Nerv #28 这个就是我想说明的，我举了个例子来证伪路由器同时接入两个重合 IP 段的情况。
但拒绝设置重合网段这是个“加法”功能，厂商不做的话就不会有这种机制，所以我留了个口子，保不齐有厂商没做这个判断，然后用户确实可以配置两个重合的网段，那么就看具体什么算法，有可能始终走物理顺序第一的口，也可能因为路由表顺序的优化走最后走过的口，也可能发生了缓冲区错误停止运行。

@polyang #54
都要改端口号了，把没必要暴露出去的端口改监听本机或局域网，成本是一样的，效果还更好。

分布式的肉鸡全端口扫描并不需要消耗黑客一秒的时间，肉鸡不值钱，有一大批物联网设备可以用，全端口扫描也就是加个循环的事，这点并发量跟 DDos 比九牛一毛都不算。

遭到分布式的全端口扫描的概率也并没有低到可以忽略的程度，毕竟门槛太低了。
不过任何安全策略就是求一个成本和风险的平衡，成本高、风险能接受就可以考虑不做。

有调试需求的话肯定 GUI 会方便很多。

有些 IDE 是跨平台的，比如 JetBrain 家的，能提供像 VS 那样顶尖的 IDE 体验。

如果愿意折腾的话，Vim 和 Emacs 都可以死命装插件堆功能的。另外 Linux 下也可以用 VSCode，只不过体验跟 VS 差得多了，不知道装插件能能靠近 VS 的体验。

还有一种方案就是在 Windows 用 IDE 来连虚拟机调试，比如 VMware 就给 VS 提供了插件，我没用过，你可以了解一下。

另外如果是非底层系统开发的话 WSL 也应该可以试一试。

如果不担心被遍历的话，可以数据库自增。

如果担心被遍历的话就用时间戳+随机数字再 HASH，只不过越短碰撞可能性越大。

当然也可以数据库自增再加随机量的增量，然后再做个风控监测，如果某客户端短时间内访问了大量的无效 ID 就封掉。

缩短 ID 的最重要的一步是做进制转换。
自增是十进制，HASH 是十六进制，如果你大小写不敏感就一律转换成 36 进制，即 0-9a-z，如果大小写敏感就用 62 进制，0-9a-zA-Z，这个如果用 JS 的话可以直接 toString(进制数)。

@AoEiuV020 #20 恩，掩耳盗铃……

有的数据库本身安全策略上有缺陷，如果没有经过仔细配置的话就容易被人连上操作，这个你只要把数据库端口暴露到外网就有风险。

另外对于关系型数据库还可以通过后端服务的 API 来进行注入，同样可能可以做到把数据导出并删库。

所有服务全走 VPN，包括 SSH 和远程和桌面，是比较稳妥的方案。

如果是企业生产用途的话，可以参照网络安全等级保护的要求，除了安全策略还有容灾备份。

如果路由器两个口可以设置重合的网段，是不是我也可以设置一模一样的网段，比如 A 口和 B 口都设置 192.168.128.0/23，那么这样的话，即便数据包会携带子网掩码路由器也是一样无法判断究竟应该转发给谁。

子网掩码一般都是设备自己知道，用于推算网络基本情况的，这个要么是走 DHCP，要么是静态配置，而不是在每个数据包发送过程中夹带的。

而路由器自己维护路由表，所以有自主权决定数据包怎么转发（而不是终端来告诉路由器应该发给 A 口还是 B 口，这样就变成了终端在越殂代疱了），通常的情况是路由器同时接入两个不重合的网段，根据发送者的 IP 和接收者的 IP 来看落在哪个 IP 段里，就走转发到哪个线路。所以如果两个网段是重合的，那么就得看路由器是什么策略，这个如果没有统一的标准的话就可能是不同路由器、不同配置会有不同结果。

把同事先 block 为敬？