chore: update doc

docs/关于清理策略的讨论.md

@@ -22,20 +22,23 @@
 
 我：
 
-> 你这个需求算是比较特殊的，因为很多 repo 是需要保留多个 tag 版本的（以便回退之类的），所以，如果你的需求就是保留最后一个 tag ，那我建议你可以在 push 前，先触发一次删除操作；“有些 image 比较稳定没什么变动, 有可能超过 60 天没有修改, 但是却一直在使用”，这个需求可以根据策略进行保留，目前的策略是额外保留 10 个，满足你的要求；
+> - 这个需求算是比较特殊的，因为很多 repo 有保留多个 tags 版本的需要（以便回退），所以，如果你的目标需求是仅保留最后一个 tag ，那我建议你可以在 push 前，先触发一次删除操作；
+> - “有些 image 比较稳定没什么变动, 有可能超过 60 天没有修改, 但是却一直在使用”，这个需求可以根据策略进行保留，目前的策略是额外保留 10 个，满足你的要求；
 
 
 我:
 
-> 针对一些超级变态的 repo ，例如每天都能创建 5+ tags 的 repo（60 天就有 300+ 了），我会单独进行特殊处理；如果觉得自己负责的 repo 有 tags 保留策略方面的问题，请及时和我沟通……
+> 针对一些超级变态的 300+ tags 的 repo ，例如每天都能创建 5+ tags 的 repo（60 天就有 300+ 了），我会单独进行特殊处理；如果觉得自己负责的 repo 有 tags 保留策略方面的问题，请及时和我沟通……
 
 路人丙：
 
 > images 是存在 S3 上面的么？tag 太多导致 index 太慢？
 
 我：
 
-> images 是保存在 S3 上的；针对 tags 来说，有些操作会基于 Harbor API 进行遍历，故存在效率问题；有可能导致某些操作的时长线性增长（目前大致估算，在 Harbor v1.2.2 版本上 60+ tags 在 UI 上手册展开在 7~12 秒左右），所以没用的 tags 都应该进行清理；Best Practice 应该是每个 project 或 repo 的负责人自行负责 tags 的清理，但目前还是由我统一先处理吧；
+> - 目前 images 是保存在 S3 上的；
+> - 针对 tags 太多的问题，怀疑有些 API 操作是基于 Harbor API 进行的遍历，可能导致执行时间随 tags 数量线性增长（在 Harbor v1.2.2 版本上 60+ tags 在 web UI 上首次展开在 7~12 秒左右），所以没用的 tags 都应该进行清理；
+> - Best Practice 应该是每个 project 或 repo 的负责人自行负责 tags 的清理，但目前还是由我统一先处理吧；
 
 路人丙：
 
@@ -63,10 +66,10 @@
 
 我：
 
-> @路人丁 目前针对 tags 的处理策略（见上面）就等价于不会完全删除掉 image ；
-> @路人丙 目前写了 [moooofly/harbor-go-client](https://github.com/moooofly/harbor-go-client) 项目用于处理这个问题（因为官方尚不支持这个功能）；
-> 针对“比如写个 crontab 脚本之类的”，目前我觉得不太需要定时执行，目前我可以每隔 15 天跑一次分析，然后再执行清除操作，可以不需要相关人员操心；
-相关人员可以提一下关于处理策略方面的建议：比如 “针对 tag ：保留 60 天内创建的所有 tag ，在 60 之前创建的 tag ，额外保留 10 个；” 这个策略是否合适；
+> - @路人丁 目前针对 tags 的处理策略（见上面）就等价于不会完全删除掉 image ；
+> - @路人丙 目前写了 [moooofly/harbor-go-client](https://github.com/moooofly/harbor-go-client) 项目用于处理这个问题（因为官方尚不支持这个功能）；
+> - 针对“比如写个 crontab 脚本之类的”，目前我觉得不太需要定时执行，目前我可以每隔 15 天跑一次分析，然后再执行清除操作，可以不需要相关人员操心；
+> - 相关人员可以针对处理策略提建议：比如 “针对 tag ：保留 60 天内创建的所有 tag ，在 60 之前创建的 tag ，额外保留 10 个；” 这个策略是否合适；
 
 路人戊：