@111111111111 输入是原始 SQL 文本，输出是改写后 SQL 文本，我们设想的是经过 parser 解析之后改写的这个中间件，不是 Django ORM 这类上层应用。不管上层是什么应用，Django ORM 也好，SQLAlchemy 也好，它看到的应该都是原始的 SQL ，也就是不察觉到分表的存在，真正执行的是被中间件层改写过的 SQL 。

所以主楼的问题是，这样的中间件有没有现成的，对不同语法覆盖比较全面的（也就是非玩具的意思）

@unco020511 是真的，但是仅是爸爸自己不想去保养。。不代表我自己买了混动之后不保养，也不倡导这种不保养的习惯..

爸爸说，当年保养过发现就是换换机油之类的，后来就再也没去过 4s 点做保养，照开不误开了 8 年。现在把老雅阁传了给我，我把新买的雅阁给了爸爸开，叮嘱他要记得 1 年去一次保养，我出钱= =

但是反正= =这个事让我意识到雅阁真的很耐开...

@RedisMasterNode 所以其实说来说去，BYD 优点很多，雅阁基本上在我看来，相比 BYD 就是耐用，耐用，耐用。其他不熟悉的方面不敢谈，但是楼主如果也会看重用多少年这种事情的话，感觉雅阁（仅指这方面）优势不小。不开玩笑开了 8 年的老雅阁洗车之后还是很锃亮，内饰自己用车也保养得很好，无异响 + 8 年 0 事故（哈哈这个就看人了，跟车没关系）。

家里两台雅阁车主，第二台就是 4 月落地的雅阁混动次顶配，落地 24w （呜呜呜购置税亏麻了）。BYD 不了解，只提一下雅阁的感受，老雅阁开了 8 年跟新的一样，整体车况都很好，买之前不相信，现在知道传 3 代是真的。耐开，只要自己不刮刮蹭蹭或者出事故，车是真的稳定不出问题，8 年我爸就保养过 1 次（ hhh ）。

再说回 4 月买的混动，对比起来感受就是，低速确实不需要发动机，安静了一些。隔音一直是弱项，但是平时城市开感觉用电机的情况下，比老的油车改善了很多，个人表示能接受。另外混动在我们这边目前是 100% 能有指标上牌的，混动车的指标每个月都有多，所以跟绿牌比好像没差。油耗现在 92 突破 9 元了，如果楼主经常跑高速的话，油费还是小贵的，如果城市路况居多的话，（虽然比不上电车但是）省油这方面完全没什么毛病，够用。

顺便问一句，雅阁混动空间大还是 BYD 大？之前试驾了 3 系和 A4 ，都没愿意买，就是因为当时我开雅阁去试驾结果发现空间小了好多，而且还比雅阁贵了差不多 10w ，一下子就不想买了。。。

@DsuineGP 是不是推广自有人判断..老屏蔽词汇，根本就不知道在说的是什么= =

不太了解字节的职位，不过看到这个 title 也很感兴趣。

我司 Infra 有负责可观测性的团队，业务项目需要的分布式追踪要怎样在不同团队、不同产品线落地，如果能有统一的统筹感觉会比较方便，它们可以提供统一的接入方式，为不同团队使用的业务框架开发插件来便于接入，还比如说对于 Tracing ，提供 Tracing 平台和采集的能力；对于 Metrics ，一般都有 Grafana 之类的，可以看看有没有一些通用的上报可以在底层统一做；对于 Logging 可以提供统一的 Log 包以及日志平台等等。

@iwdmb 下次可以试试。不过说什么营销厉害的，感觉不太赞同，讲这些没有意思，工具或者团队是需要有合适的人来运营，这不是比较的理由，你只需要强调出你推荐的工具的优点就足够了

@Mitt 感觉是自定义和扩展的能力吧，gin 本身提供的 feature 不是很多，它不是 django 那种大包大揽全集成的框架，更像 flask 很多东西都得自己开发。用 go 的大公司居多，有独立开发脚手架、扩展插件，或者对整个框架二次开发的能力，所以选用 gin 的挺多的

仔细看了前面一些，写得挺好的加油

@lesismal 然而实际工程里面这个项目结构挺好用，不管 rcox 喷还是不喷，适合的就是好的。实践里面我们很多工程都按这个目录来，也清晰明了没出现什么问题。

所以也不存在什么受害人，要我说盲目跟风 rcox 的才是受害人

复制楼上这句，Github 企业版，GitHub 配套的 CI/CI, issue , PR, project, release 什么的都是用起来最舒服的。

表示真的很好用，而且 Github 配套的插件也很多，如果你们想在 GH 上做 code review ，也很好用！！

喜欢，而且部门应该鼓励做这个事情，例如按 review comment 量来予以奖励