不，你的问题是，有什么好用方便管理的私有云备忘录系统

为什么你会觉得电脑断电后需要去手动检查文件错误？
一个 ext4 分区，拿 windows 的软件去修复，你觉得可靠吗？

除非你写的东西一辈子都不会改，否则学会模块化。不管是后端业务还是前端渲染或者两者交互的接口。
使用一个大接口，以后改一次就欲仙欲死。页面出问题，排查过程也太过复杂。
以一个典型的商品展示页举例，展示图、库存、价格、详情、退货条款，你确定要把这些东西全部放一个接口？
怎么有些前端的还想争话语权？我知道这里前端多，可是前端又不需要承担业务责任和架构设计，你们怎么争话语权？能不能做，怎么做是后端说了算。

@est 我始终没看明白哪里有歧义，/不就是目录吗？ git 相比普通文件系统无非多了个限制，不允许目录和普通文件重名，这很好啊。我自己就是用 cli ，没觉得有什么需要特别注意的。可能需要多敲一 f 的单词
ls .git/refs/heads/feature 看到的就是 feature/前缀的分支名，不觉得有什么奇怪的。
既然 git 原生就支持/作为目录，那我觉得设计理念里就有建议大家使用/来区分的意思。当你有一堆文件，我相信大家都不会全部放在一个目录里吧，都会按领域分到不同目录，git 里的/就说这么设计的啊
我基本也不是手动写 push 分支，alias gpsup='git push --set-upstream origin $(git_current_branch)'够用
@est

我现在是桥接模式导致 iptv 用不了，但是又没时间精力去看网上教程把 iptv 打通

@Paranoid1119 这个问题我已经有一个月了，验证还不能成功。每次都要返回重新打开

我最讨厌图文无关的公众号，有些人配图完全是随便找个网图就来了

可以啊，但是带来的效果更像是把分布式链路集成到了结构化日志中。
一般来说 trace 更倾向于组建链路，跨日志查询 trace id 是一种跨日志查询效果，跟 trace 本身关系不太大，虽然可能需要链路信息

所以，什么时候提供付费代刷开源 PR 的业务

一万条数据，qps 不到 1 万，这你随便用什么东西都能搞定的事情，你确定瓶颈是在查询数据本身吗？

大部分人不过是混口饭吃，简单来说就是，所有职业的大部分从业人员都是屎。

@S179276SP 实际上，被拖拉机剥夺工作机会的人力车夫，根本没机会去拖拉机流水线打螺丝。不只是劳动力需求量，更是技能点问题。你在这里想象 AI 是万能的，不如你建个 AI 神教。

@RiverMud 我觉得他说的佣金可能是指薪水待遇

月薪 3k 的时候，要攒两个月才能买一个 ipad ； 5k 的时候，一个月剩下的钱差不多够 ipad 了； 10k 的时候不再觉得买 ipad 是个负担。
随着收入的增长，我工作时长越来越长，下班时间越来越晚。5 点-6 点-7 点-8 点。