zealotpuppy

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

@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 的业务