@cjzlol 我明白你们的意思，我的意思是，这样不是最符合楼主利益的处理方式，但没说这样为人处事有什么问题。只是怕大家一股脑的给这种强硬做法点赞让楼主麻木了。

@yuzhibopro 这不成了狗咬狗了吗？你愿意和别人计较，实际上难受的是你自己。楼主因为对方的失误产生了损失，生气很正常，但是不同的人面对这种情况的处理方式区别很大，哪种好哪种坏，就冷暖自知了。

好像没人认为你有问题，我再多评论一句。
你这句话对方根本没办法回答，反而显得你自己很小气，是那种得理不饶人的人，我印象里这类性格的人最明显的特征就是外卖超时了一定投诉，快递放柜子里宁可退货也不自己下楼取之类的。

你这句话一说出来，就等于撕破脸了，就谁也别嫌弃谁了属于是

「你这瓜保甜吗」

http://js.jsrun.net/RQVKp

处理省市区什么的写的比较难看，大概就是这个思路吧
通过一个 hash 做映射，方便找到父节点

m1 几乎在所有评测吊打 intel 。好像还没看到 intel 真正意义上赢一次。

sp6 狂喜。

但是...会不会只是因为重做了系统？

@learningman 写 CI 那是真的...，好在我们用 drone，还可以本地执行

看了这么多还用别人推！

宁美国度就完了

淘宝 228 买的，129 有点过分了啊亲！

火星了，只火星了一点点

https://web.dev/text-fragments/

我们项目里已经用上了，给不知道的演示一下，下边的地址复制到浏览器打开。


还支持指定 start 和 end，挺不错的功能，有些搜索引擎已经开始支持了

https://v2ex.com/t/784212#:~:text=好像还挺好用的

@work19990909 no，ns 版本需要单独买，还卖的挺贵

@learningman 频繁通过 commit 触发 ci 并不是常规操作吧，我们要求本地 test 过了之后提交。如果 pr 里边的 ci 失败了，修改后的代码直接 rebase 到提交记录里去，pr 里的提交记录必须是干净的。
rebase 掉的 commit 是不会记录在这里的

1400 contributions in the last 12 months

图一体现「改造+升级」，图二体现了「纯升级」。哪个都不能算错吧

常见的系统设计中，一般是以下 3 个情况

- 登录返回信息
- 登录不返回+独立获取信息接口
- 登录返回+独立获取信息接口

前端通常会将用户的信息持久化到本地，方案如 cookie 或者 local storage，至少也是使用 redux 之类的工具在内存里留一份，避免需要的时候只能再次请求接口

你好像还提到了读操作，读操作思路没研究过，不过读操作限制起来终究是简单一点，比如你可以在 model 的__init__阶段判断当前用户有没有权限获取这个实例，想读就一定需要实例化嘛。
不过这种方式局限性也很大，还是得根据项目判断。

我也有一阵子没写 Django 了，不过还能扯两句。

你的思路问题不大，因为动表的 api 真的很少。实例的 save 、delete，和 manager 的 delete 、bulk_create 、bulk_update 。
https://docs.djangoproject.com/en/3.2/ref/models/querysets/

前两个很好操作，你可以直接在 model 上修改，三年前我写过一篇相关的内容，不过当时是记录操作日志，不是权限控制 https://segmentfault.com/a/1190000015022691 当初也是年轻哈哈写的什么玩意

manager 方法大部分会调用 model 的 save，但是批量操作的都不会，也就是 delete\bulk_create\bulk_update 。如果你想让别人用的爽一点，这里就得多做点工作。

判断权限需要得到当前登录的用户，这一点其实挺烦的，Django 没有 flask 的 g，orm 层也没有请求上下文，你通过什么办法在 orm 层面得到请求上下文？这也是你需要解决的问题

related： https://stackoverflow.com/questions/3227180/why-is-using-thread-locals-in-django-bad