和 Codex 一块儿搓了个新前端 hu60next
@残缘 #162 github main 基线已 reset 为 cf12a82bc6b2e3746fbc961c2e410475039365fd
@七号，@残缘，我已新增 _myself=countReview 用于随时获取待审核内容数量，会返回 countReview 和chatCountReview（与首页的数据相同）。 请对接口进行替换，还有，希望你们未来也不要为了获取某个数据而高频访问不相关的API。如果数据能在一个请求内获得，就不应该发起第二个请求。
_myself=countReview
countReview
chatCountReview
测试
@七号，@残缘，还有，希望你们不要再单独请求user.stat接口，使用 _myself=countReview,permissions,newMsg,newAtInfo,newChats 代替。如果有不能代替的地方就告诉我，我去改。
user.stat
_myself=countReview,permissions,newMsg,newAtInfo,newChats
@七号 #164 还有访问首页的时候为什么一直在调用 bbs.forum 接口？ 这是预取吗？能关掉所有预取吗？虎绿林的服务器不是为预取设计的，预取消耗的带宽和算力只能让所有人变卡，包括预取的发起者。
bbs.forum
视频链接：SVID_20260730_161932_1.mp4（8.08 MB）
也许应该添加一个独立的深色模式开关，有些人的浏览器可能无法跟随系统进行深色模式切换
@tasy5kg #171 这个大概是密码输入框是 type="text" 的缘故，是有意这么做的。因为为了让密码框能在手机上输入中文、emoji等字符，现在是用 CSS 做的遮挡。
type="text"
还是改为 type="password" 合适，毕竟中文、emoji等字符做密码是小众。
type="password"
https://github.com/rkonfj/hu60next/pull/8#pullrequestreview-4820373539
@老虎会游泳 老虎帮忙确认下hu60wap6用户偏好排序是不是这样的
@残缘 帮忙确认下是不是忽略了hu60wap6 本身已经存在的排序偏好
这个 PR 应该只需要做到或确认这些:
这个 PR 代码量完全可以控制在 200 行以内
@七号，分析的很对，排序确实是这样工作的。
还有为了减轻服务器压力，我已经努力让前端可以在单次请求中得到所需的所有信息，所以请各位尽量不要在单次访问中请求多个接口（特别是在最常用的帖子页面更不应该发多个请求）。如果在单次请求中拿不到所需信息，应该和我沟通，我会提供解决方案。
@老虎会游泳， 为什么现在要修改后端，当年我做的两版，都没让你改过后端
@胡椒舰长，因为 https://hu60.cn/h5/#/pages/page_topic_show/page_topic_show?topic_id=107456 只会请求一次后端接口， 但 https://next.hu60.cn/topic/107456 会请求3次（备注：之前会请求十几次，遇到的每个用户都会请求一次user.info接口，现在已经是优化之后的结果了）。 为了减少请求数量，我必须在同一个页面内提供hu60next所需的全部信息。
user.info
@七号，@残缘，能不能继续优化，争取做到访问 https://next.hu60.cn/topic/107456 只请求一次后端接口？ user.stat.json?pageSize=1已经完全可以用 _myself=countReview,permissions,newMsg,newAtInfo,newChats 代替了，现在没有任何理由继续请求它。
user.stat.json?pageSize=1
还有为什么帖子内容页面要请求bbs.forum.215.1.0.json?pageSize=30&_topic_summary=180&_uinfo=name%2Cavatar&_time=1啊，谁能给我一个解释？
bbs.forum.215.1.0.json?pageSize=30&_topic_summary=180&_uinfo=name%2Cavatar&_time=1
@老虎会游泳 #180 就是 prefetching。已经改为不预取了
@残缘 #162 github main 基线已 reset 为 cf12a82bc6b2e3746fbc961c2e410475039365fd
@七号，@残缘，我已新增
_myself=countReview用于随时获取待审核内容数量，会返回countReview和chatCountReview（与首页的数据相同）。请对接口进行替换，还有，希望你们未来也不要为了获取某个数据而高频访问不相关的API。如果数据能在一个请求内获得，就不应该发起第二个请求。
测试
@七号，@残缘，还有，希望你们不要再单独请求
user.stat接口，使用_myself=countReview,permissions,newMsg,newAtInfo,newChats代替。如果有不能代替的地方就告诉我，我去改。@七号 #164 还有访问首页的时候为什么一直在调用
bbs.forum接口？这是预取吗？能关掉所有预取吗？虎绿林的服务器不是为预取设计的，预取消耗的带宽和算力只能让所有人变卡，包括预取的发起者。
视频链接：SVID_20260730_161932_1.mp4（8.08 MB）
也许应该添加一个独立的深色模式开关，有些人的浏览器可能无法跟随系统进行深色模式切换
@tasy5kg #171 这个大概是密码输入框是
type="text"的缘故，是有意这么做的。因为为了让密码框能在手机上输入中文、emoji等字符，现在是用 CSS 做的遮挡。还是改为
type="password"合适，毕竟中文、emoji等字符做密码是小众。https://github.com/rkonfj/hu60next/pull/8#pullrequestreview-4820373539
@老虎会游泳 老虎帮忙确认下hu60wap6用户偏好排序是不是这样的
@残缘 帮忙确认下是不是忽略了hu60wap6 本身已经存在的排序偏好
这个 PR 应该只需要做到或确认这些:
这个 PR 代码量完全可以控制在 200 行以内
@七号，分析的很对，排序确实是这样工作的。
还有为了减轻服务器压力，我已经努力让前端可以在单次请求中得到所需的所有信息，所以请各位尽量不要在单次访问中请求多个接口（特别是在最常用的帖子页面更不应该发多个请求）。如果在单次请求中拿不到所需信息，应该和我沟通，我会提供解决方案。
测试
其他几点也都覆盖了：① 设置页可改默认排序；③ 回帖/编辑回跳用 ?floor=N；④ 审核按 topic.floorReverse 校验；⑤ 列表箭头同样用 ?floor= 跳最后一楼。之前写死正序的问题已去掉，现在完全跟服务端返回走。
帖子页审核时会带上当前页实际排序（topic.floorReverse），审核接口按同一排序拉取楼层做校验，倒序下也能对上。第 2 页起补主楼是为避免多页场景审核失败，如需要可以单独拆 PR。
@老虎会游泳， 为什么现在要修改后端，当年我做的两版，都没让你改过后端
@胡椒舰长，因为 https://hu60.cn/h5/#/pages/page_topic_show/page_topic_show?topic_id=107456 只会请求一次后端接口，
但 https://next.hu60.cn/topic/107456 会请求3次（备注：之前会请求十几次，遇到的每个用户都会请求一次
user.info接口，现在已经是优化之后的结果了）。为了减少请求数量，我必须在同一个页面内提供hu60next所需的全部信息。
@七号，@残缘，能不能继续优化，争取做到访问 https://next.hu60.cn/topic/107456 只请求一次后端接口？
user.stat.json?pageSize=1已经完全可以用_myself=countReview,permissions,newMsg,newAtInfo,newChats代替了，现在没有任何理由继续请求它。还有为什么帖子内容页面要请求
bbs.forum.215.1.0.json?pageSize=30&_topic_summary=180&_uinfo=name%2Cavatar&_time=1啊，谁能给我一个解释？@老虎会游泳 #180 就是 prefetching。已经改为不预取了