mark
之前看过一个 html2canvas 的类似功能的项目，做意见反馈时网页内截图会用到

ctrl+u 看了一下 QQ 空间的源码，甚至还有中文注释，看起来是根本没有用任何前端打包工具之类的，有一些链接也是指向.php 结尾的网页，我都怀疑是 php 用 echo 直出的网页
QQ 空间这些技术栈应该也都很老了

我实习的公司买过 tailwindcss ui 的一些付费模板和组件库，其实就是给一个账号密码，登录后能看到源码，其实理论上确实可以按照你所说的把源码下载下来然后免费发到网上给别人用，但是我也不知道为啥没人这样干，可能是外国人版权意识比较高吧
而且这种付费 UI 很多是有融资 or 准备上市的公司网站在用，应该没有老板会希望自己的公司网站在这个阶段被查出在用破解版 UI 。

有点好奇这个限制是谁设定的呢？是服务商(例如 openai)还是发卡行？
如果是发卡行的话他是怎么判断我当前付款的服务和 AI 有关联？难道是发卡行这边维护了一个服务商黑名单？

但凡去查过 parody 的中文意思后都不会问出这个问题

@gmyxds 看起来是 CloudFlare 的 CDN 后台

很好奇楼主这是什么网站？

MySQL 5.6 之后好像支持创建 FULLTEXT 索引，不知道有人试过这个功能没？顺带问问 MySQL 的 FULLTEXT 索引好不好用？

请问这个封禁是整个腾讯云帐号被封还是只是删除机器而已？

我的微软账号也是 QQ 号。
查登陆日志发现我最近两天也收到了十几个登陆失败的记录，来自中国各地的 IP ，不过都是错误的密码，看来我的正确密码没有被泄露。
理论上中国都是实名制上网，如果网警愿意做事并且微软愿意配合网警提供登陆日志的话，这种黑客是可以顺着 IP 的分配时间抓到的，不然也有可能是这些家宽本身就是肉鸡，被黑客利用了。

查登陆日志发现我最近两天也收到了十几个登陆失败的记录，来自中国各地的 IP ，不过都是错误的密码，看来我的正确密码没有被泄露。
理论上中国都是实名制上网，如果网警愿意做事并且微软愿意配合网警提供登陆日志的话，这种黑客是可以顺着 IP 的分配时间抓到的，不然也有可能是这些家宽本身就是肉鸡，被黑客利用了。

@xngiser 我个人猜测这样会和微信企业版有利益冲突，他们不愿意这样做。

@ysc3839 谢谢回复，我已经试过我手头上所有的银行卡，全都这样

@oneisall8955 请问你是借记卡还是信用卡呢？我试过我的借记卡无法绑定，如图所示 https://x.com/changwei1006/status/1841754078747230539

@yanghanlin 这个方法我试过了，也没用，我甚至试过换别的手机号也不行

@liuqiongyu889 你是如何确定用了 use client 的组件是没有 SEO 的？你有用 Google 的 Search Console 验证过吗？我用最新版 next.js 14 是可以的，而且查看使用 use client 的页面组件的 HTML 源代码也是能看到有做服务端渲染。

如果要实现客户端局部刷新，那么 RSC 里面就只是单纯的获取数据就好了，把真正的页面组件写在 RCC 里面，然后再用 useSWR 的 fallback 属性预先注入来自服务端的数据，后续请求都由 SWR 发起，这样就是和传统的 pages router 一样的效果，既不会损失性能又可以用到 app router 的 layout 功能保持住 layout 部分的状态。（况且我不觉得 RSC 那一定点 JSON 真的会损失多少性能，我们真实上线的用 next.js 做的书单品项目录展示类网站，一页 30 本书籍左右的内容，RSC 在 gzip 之后才不到 5kb ，加上 HTTP2 的长连接，传输 5kb 数据基本可以忽略不计）

客户端渲染：Next.js 一样可以用啊，加上 use client 指令之后对应的页面就是首次访问是 SSR ，然后用 next/link 的 Link 组件点击或者 useRouter 的 push 也是客户端渲染，路由体验一点也不差啊

缓存数据：这不是后端输出 API 时需要在 header 设置强制缓存和协商缓存的吗？然后 vercel （ next.js 的母公司）本身也有推出 useSWR 啊，stale while revalidate 的理念就是缓存+后台刷新，体验也不差啊

BBF：BBF 为什么要跳过？ Next.js 的 CSR 服务端组件直接就是 BBF ，少了一层单独的 BBF 代码，维护性好了很多

自由度：看你怎么取舍，软件开发没有银弹，我之前也试过不用任何框架，手动用 react-dom/server 处理 SSR ，手动用 import()+React.lazy 做路由分割，手动用 webpack 打包精准控制每个 plugin 和 loader 参数以及公共 vendor 包的分割，然后发现自己花了大量时间处理工具链问题，不如 next.js 官方的默认配置来的好用，甚至性能还有所降低。举个例子，如果用了 css module ，你自己不花一番功夫配置各种 ts 插件，在 VSC 或者 WebStorm 等主流开发工具里面是无法做到 F12 点击 css module 的 className 名称后自动跳转到原始 css 文件对应的 className ，如果你看过 next.js 官方的源码你会发现他做了非常多的类似的优化以及各种方便开发者的组件

目前来看 remix 最大的优势是开发阶段用的是 vite ，hot-reload 速度比 next.js 的打包后提供预览的方式要快很多。我昨天刚好在看 turbopack 的文档，里面有提到 next.js 为什么不用 vite 或者浏览器暴露原生 ESM ，https://turbo.build/pack/docs/why-turbopack

我之前也在 twitter 提到过 remix 和 next.js 的差别 https://x.com/changwei1006/status/1819012445643645186 。怎么选择就看你本人对 Vercel 和 W3C 标准化组织的哪个更有信心和期待。next.js 的理念就是目前前端标准进步速度太慢，这种环境下做一些激进的优化很困难，干脆我自己用 Next.js ，next/image ，next/font ，SWR ，RSC 来解决路由，图片，字体，缓存，交互等方面的性能，而 remix 是尽可能使用前端标准下的各种方案做优化。

目前来看我个人还是觉得 Vercel 的影响力，技术实力和在用户体验方面的推动力要比 W3C 大很多，所以我会选择 next.js ，这也是大部分开发者的观点和选择。

面向对象的写法问题主要在于会把同一个业务逻辑的代码分散到多个 lifecycle ，而 hook 刚好解决了这个问题
至于 useState 这种内置 hook 只是因为 function 的写法没办法调用 this.setState 而创立的
Java 这些传统面向对象编程语言其实有用 annotation+AOP 的方式来解决业务逻辑必须要分散到多个生命周期的问题，而 JavaScript 这边的 decorator 好像迟迟没有纳入 ECMAScript 标准，除了 nest.js 和 mobx 以外比较少有框架在用“非标准”的 decorator 特性

很好奇自建 mail 服务器要怎么做呢？云服务商好像普遍都封了 SMTP 的 25 端口。
自己有独立 IP 的情况下，如果发多了垃圾邮件好像还是一样会被运营商封 25 端口吧？！