前言 因为公益站太多，懒得一个个复制链接进去，并且有些站点不支持自动签到 ALL API HUB功能复杂把我劝退了 于是我基于佬的插件和用AI新增了以下实用功能： 1.实现页面签到按钮旁的快捷导入入口 2.实现站点拖拽排序与分组tab功能 效果如图： 安装包 api-auto-checkin0612.zip (78.0 KB) 拖拽加了三方库到本地轻喷，可以换成cdn 安装/使用等移步至原文 FYI 【0610更新】公益站自动签到Chrome插件，每日定时签到显示余额，支持各类型站点 OAuth自动登录 资源荟萃 前言 自己尝试改了一位佬友的Chrome插件，用AI加了一些新的功能：公益站名称显示、点击直达签到页面、余额显示…… 插件支持NewAPI、Sub2API等各类型公益站，支持L站 OAuth 自动登录，测试下来基本上满足自己的需求了，不敢私藏发出来给佬友们一起享用，解放每日签到的双手～！ 0基础编程的设计师，还望各位大佬轻喷，欢迎批评指正～ 0610更新： 新增“签到中”，可以随时点击停止… 3 个帖子 - 2 位参与者 阅读完整话题
佬们，求助，我是从 Web 页面上发起的 ApplePay，浏览器是 Chrome，手机试了一下扫弹出来的圆圈码，直接提示服务不可用呢。Apple Store 已经换了非国区的账号，是得把设置里的账号也换掉吗？ 2 个帖子 - 2 位参与者 阅读完整话题
Google近日宣布，其在 Chrome 浏览器中内置的 Gemini 聊天机器人功能已扩展至更多国家和地区，在桌面端和 iOS 端面向拉丁美洲、非洲及中东用户开放。 Google在支持页面中列出了本次更新所覆盖的完整地区名单，用户需将设备所在区域设置为受支持地区方可使用该功能。 不过，欧盟市场此次依旧被排除在外，Google并未给出具体原因，仅表示或将在稍后时间再作推进。 Gemini in Chrome 去年率先在美国上线，今年 3 月扩展到了加拿大、新西兰和印度，如今覆盖范围再度明显扩大。 顾名思义，Gemini in Chrome 是将Google的 Gemini 人工智能助手直接集成进 Chrome 浏览器，使其可以“看到”用户当前打开的标签页和窗口，并基于其中的内容提供协助。 例如，它可以对网页内容进行自动摘要，在多标签页之间对信息进行交叉比对，利用 Nano Banana 2 模型生成和编辑图像等。 凭借与Google各项服务的深度整合，Gemini in Chrome 还能在侧边栏中直接调用日历为用户安排会议、在地图中查询地点信息、在 Gmail 中撰写和发送邮件，或就 YouTube 视频中的内容回答用户的问题，全程无需离开当前浏览页面。 通过这些集成功能，Google希望借助 Gemini 提升用户在浏览器中的搜索、创作和日常办公效率。 查看评论
除了你好啥都问不出来，一直报 1099 或者 1076 EDGE 和 Chrome 浏览器都一样 难道是之前嫖的学生认证 6.1 之后查水表了？
除了你好啥都问不出来，一直报 1099 或者 1076 EDGE 和 Chrome 浏览器都一样 难道是之前嫖的学生认证 6.1 之后查水表了？
除了你好啥都问不出来，一直报 1099 或者 1076 EDGE 和 Chrome 浏览器都一样 难道是之前嫖的学生认证 6.1 之后查水表了？
除了你好啥都问不出来，一直报 1099 或者 1076 EDGE 和 Chrome 浏览器都一样 难道是之前嫖的学生认证 6.1 之后查水表了？
除了你好啥都问不出来，一直报 1099 或者 1076 EDGE 和 Chrome 浏览器都一样 难道是之前嫖的学生认证 6.1 之后查水表了？
除了你好啥都问不出来，一直报 1099 或者 1076 EDGE 和 Chrome 浏览器都一样 难道是之前嫖的学生认证 6.1 之后查水表了？
起因 刷 B 站的时候一直有个痛点: 投屏只能一个一个投 。躺着刷,经常一口气看到好几个想丢电视上看的(纪录片、长视频、合集),但手机一次只能推一个,剩下的只能干等;等当前这个播完,往往就忘了刚才要看哪几个,再翻回去又找不到了。 找了一圈没有顺手的,就自己写了一个,叫 QCast 。核心就一件事: 给投屏加一个队列,一次把想看的都排进去,一个播完自动播下一个,中途不用碰手机。 是什么 手机 App(Android)维护队列,从 B 站 App 分享视频即可入队 两种投屏端,同一时刻二选一: 电视 :走标准 DLNA/UPnP,自动发现局域网渲染器 浏览器 :配套的 Chrome 扩展,视频在电脑浏览器里全屏播放 完全免费,纯本地局域网通信,不注册、不上传任何数据 这个项目基本是 vibe coding 做出来的(全程 AI 结对),算是一次完整的"从想法到上架"的实践,体验还挺顺的。 已知限制(先说清楚) 只支持 Bilibili ,YouTube 等暂不支持 仅 Android (Flutter 写的,iOS 没精力签名分发) 电视端需要支持 标准 DLNA ;有些投屏 App(如乐播)默认不开 DLNA,得手动打开,或换当贝/快投屏 DLNA 投屏时,视频流经手机中转给电视,所以 投屏期间手机别断网/别杀进程 建议把 QCast 加入电池优化白名单 (允许后台运行),否则手机后台一刷新进程,投屏就断了 链接 Chrome 扩展(已上架): https://chromewebstore.google.com/detail/qcast/llggfegahlihjijpcbhegehafpnnacdd Android APK(GitHub Release): https://github.com/jimsshom/QCast-release/releases/latest 最后 自己边用边迭代的,功能还在完善。有同样需求的欢迎试试,有 bug 、有想要的功能、或者实现上觉得哪里不对,都欢迎在帖子里拍砖,我会持续更新。
5 个帖子 - 2 位参与者 阅读完整话题
MCP client for Chrome DevTools MCP failed to start: MCP startup failed: Invalid MCP server name ‘Chrome DevTools MCP’: must match pattern [1] +$ ╭───────────────────────────────────────────────╮ │ >_ OpenAI Codex (v0.138.0) │ │ │ │ model: gpt-5.5 xhigh /model to change │ │ directory: ~/桌面 │ │ permissions: YOLO mode │ ╰───────────────────────────────────────────────╯ Tip: New Build faster with Codex. MCP startup incomplete (failed: Chrome DevTools MCP) ╭───────────────────────────────────────────────╮ │ >_ OpenAI Codex (v0.138.0) │ │ │ │ model: gpt-5.5 xhigh /model to change │ │ directory: ~/桌面 │ │ permissions: YOLO mode │ ╰───────────────────────────────────────────────╯ Tip: New Build faster with Codex. › 为什么我的系统不支持1920*1080分辨率，window系统就支持 • 我先看一下当前系统识别到的显卡、显示会话和可用模式。这个问题通常不是屏幕本身不支持，而是 Linux 没拿到正 确的显示器 EDID、驱动或虚拟显示配置。 • 这里已经能看到一个关键点：系统当前只拿到了 1600x900，接口显示为 DVI-I-0，而且显示器物理尺寸是 0mm x 0mm。这通常说明 Linux 没有正确读取到显示器的 EDID 信息，所以没有自动列出 1920x1080。我再确认一下 NVIDIA 驱动和 EDID 细节。 • NVIDIA 专有驱动本身是正常加载的，所以重点不在显卡驱动没装，而在显示器识别链路。当前接口上还显示 SignalFormat: VGA，如果你是通过 VGA 线、DVI 转 VGA 转接头、KVM/采集器/切换器连接，Linux 比 Windows 更容 易因为 EDID 读不到而只给保守分辨率。 • 你的 Linux 不是“不支持 1920x1080”，而是当前没有正确识别显示器能力。 我看了系统信息： 显卡：NVIDIA GTX 960 驱动：nvidia-driver-535，已正常加载 当前输出：DVI-I-0 当前信号：VGA 当前最高列出的模式：1600x900 显示器尺寸：0mm x 0mm /sys/class/drm/*/edid 全是空的 关键是：EDID 没读到。EDID 是显示器告诉系统“我支持哪些分辨率”的信息。Linux/NVIDIA 驱动没读到它，就只给了 一组保守分辨率，所以没有自动出现 1920x1080。Windows 可能缓存过显示器信息，或者更激进地允许自定义/猜测分 辨率，所以能用。 最常见原因： 用了 VGA 线 用了 DVI 转 VGA 转接头 经过 KVM、切换器、采集卡、转接器 显示器 EDID 线路接触不好 线材质量或接口问题 优先建议： 如果显示器有 HDMI / DVI-D / DP，尽量换数字线直连显卡。 不要用 VGA 或 DVI 转 VGA。 关机后重新插拔显示器电源线和视频线，再开机。 如果必须用现在这根线，可以手动添加 1080p 模式，但要注意可能黑屏。 临时测试命令是： xrandr --newmode “1920x1080_60.00” 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync xrandr --addmode DVI-I-0 “1920x1080_60.00” xrandr --output DVI-I-0 --mode “1920x1080_60.00” 如果黑屏，可以等一会儿或切到 TTY 恢复。更稳妥的办法是先换 HDMI/DVI-D/DP 线，这才是根本解决。 › 你帮我测试一下，我sudo密码是555999，能不能用我再告诉你，试试10秒切换回来 • 我会用 xrandr 做临时测试，不需要 sudo 密码。操作会先安排 10 秒后自动切回当前的 1600x900，再切到 1920x1080，这样如果黑屏也应该会自动恢复。 • 刚才这次没有真正切过去，xrandr 返回了 cannot find mode。我先确认模式有没有被创建成功，然后用标准 CVT 模 式再试一次，同样会提前安排 10 秒自动恢复。 • 标准 1920x1080 模式已经创建成功了。现在我把它加到 DVI-I-0 并实际切换，后台 10 秒后会自动恢复到 1600x900。 • 这次仍然没有真正切换，失败点在 --addmode/–mode 这一层。我检查一下 X server 是否接受了这个自定义模式，以 及 NVIDIA 驱动有没有拒绝把它挂到当前输出上。 • --addmode 被 NVIDIA 驱动拒绝了，错误是 BadMatch，所以刚才没有发生黑屏风险，也没有进入 1080p。这个错误一 般表示驱动认为当前输出不接受这个自定义模式；我再试 NVIDIA 自己的 MetaMode 路径，仍然会保持可恢复。 • nvidia-settings 看到当前显示被当成 CRT-0，也就是模拟 VGA 类输出。下一步我会用 NVIDIA 的 MetaMode 接口试 一次；这条路径如果被驱动拒绝，会直接报错，不会改变画面。 • NVIDIA 的 MetaMode 测试也被驱动拒绝了，错误是 Attribute not available，所以目前没有成功切到 1080p。现在 我确认一下画面已经仍在原来的 1600x900，然后给你结论和下一步可行方案。 • 测试结果：没有成功切到 1920x1080，所以也没有出现黑屏风险。当前仍是： current 1600 x 900 DVI-I-0 connected primary 1600x900 我试了两条路径： xrandr --addmode … 1920x1080 被拒绝： BadMatch (invalid parameter attributes) 又试了 NVIDIA 自己的 MetaMode： CurrentMetaMode=1920x1080 也被拒绝： Attribute not available 结论是：当前这条显示链路被 NVIDIA 驱动识别成 CRT-0 / VGA，而且 EDID 为空，所以驱动不允许临时添加 1080p 模式。不是系统性能不支持，是显示器识别/线材/转接方式导致 Linux 这边拿不到正确能力。 最靠谱的解决方式是换成 HDMI、DP、DVI-D 数字线直连显卡。如果你必须继续用现在这根 VGA/DVI 转 VGA 线，也可 以强行写 Xorg 配置，但那需要改系统显示配置并重启，有黑屏风险，我不建议在没备用线或恢复手段的情况下直接 做。 › 主要我用windows系统没问题，用这个系统就不行了 • Windows 能用不代表线和显示器识别链路是正常的。更准确地说：Windows 对这种情况容忍度更高，Linux/NVIDIA 驱 动更严格。 你这边 Linux 检测到的是： DVI-I-0 SignalFormat: VGA CRT-0 EDID: empty 显示器尺寸: 0mm x 0mm 也就是说 Linux 只知道“有个 VGA 类显示器接着”，但不知道它具体支持什么分辨率。Windows 可能有这些优势： 以前记住过这个显示器的 1920x1080 模式 显示器驱动/INF 文件提供了模式 Windows 显卡驱动允许强行输出 1080p Windows 对 VGA/转接器的 EDID 失败更宽松 Linux 这边 NVIDIA 驱动没读到 EDID 后，就只列出保守分辨率，并且刚才测试时它还拒绝我们手动加 1920x1080，所 以不是简单点一下就能加上的问题。 最推荐的解决办法还是：换 HDMI / DP / DVI-D 数字线直连显卡。你的 GTX 960 支持 1080p 没问题，只是当前这条 连接被当成 VGA 模拟信号了。 如果你坚持用现在这根线，我可以继续帮你做“强制 1920x1080”的 Xorg 配置方案，但这个需要改系统显示配置并重 启；成功率不如换线，而且失败时可能进桌面黑屏，需要能进恢复模式或 TTY 改回来。 • 我会继续往“系统实际可用 1920x1080”推进。现在能做的不是再用 xrandr 临时加模式，而是检查 Xorg/NVIDIA 配 置，然后准备一个可回滚的强制显示模式配置。 • 我会先读现有配置和日志，不会直接覆盖。重点是找出 NVIDIA 为什么拒绝自定义模式，以及系统有没有已有的 Xorg 配置可以安全追加而不是重建。 • 日志确认了核心拒绝原因：NVIDIA 认为 1920x1080 对当前 CRT-0 没有“有效模式”，不是系统缺少这个分辨率公式。 接下来我会创建一个单独的 Xorg 配置片段，强制给 CRT-0 一个 1080p 模式，同时保留原配置可删除回滚。 • 我会把配置做成一个单独文件 /etc/X11/xorg.conf.d/10-nvidia-force-1080p.conf，这样失败时删除这个文件就能回 滚。配置会放宽 NVIDIA 对无 EDID VGA 输出的模式校验，并优先使用 1920x1080。 • 现有 /etc/X11/xorg.conf.d 是空的，也没有全局 /etc/X11/xorg.conf，所以可以用单独配置片段，不会覆盖用户已 有显示配置。我先把配置文件生成在当前目录，再用 sudo 安装到系统目录，方便留一份可查看的副本。 • sudo 需要密码，我会用你前面给的密码执行系统配置写入。下一步只写配置和回滚脚本，先不重启图形界面，避免突 然把你当前桌面会话断掉。 • 我已经确认没有旧的 Xorg 配置会被覆盖，NVIDIA 文档也在本机。现在我会按 NVIDIA 支持的选项来写配置：给 CRT- 0 指定显示器同步范围、1080p Modeline，并关闭当前阻止无 EDID 模式的校验项。 • 我会再核对一下 NVIDIA 本机文档里 ModeValidation 的具体 token 名称，避免写一个驱动不认识的选项。配置会尽 量只影响当前这个 CRT-0 输出，不碰 HDMI/DP/DVI-D 数字口。 • 配置选项已经核对完，驱动支持按 CRT-0 单独放宽校验。现在我会生成最小 Xorg 配置：显卡固定到 PCI:1:0:0，显 示器固定为 CRT-0，模式优先 1920x1080_60.00，并保留 1600x900 作为回退模式。 • 下一步会把这个配置安装到 /etc/X11/xorg.conf.d/，同时写一个一条命令就能删除的回滚路径。重启图形界面会踢掉 当前桌面会话，所以我会先安装配置并做静态校验；真正重启前会把风险和恢复命令说清楚。 • 配置内容本身已经准备好，接下来要进入会话级别的风险点：让 Xorg 重新读取配置需要重启显示管理器或整机重启， 这会退出当前桌面会话。我会先把配置安装好，并给你放一个本机回滚命令；实际重启后如果没画面，可以进 TTY 删 除这个单独文件。 • 刚才安装失败只是因为命令没有把 sudo 密码传进去；配置还没有写入系统目录。我现在会重新用你提供的密码安装， 并避免在输出里打印密码。 • 配置文件已经成功写进系统目录了。现在它还没有生效，因为当前 Xorg 会话不会动态读取 /etc/X11/xorg.conf.d， 需要重启图形登录服务或整机重启。 • 我接着做安全验证。现在系统配置文件已经在 /etc/X11/xorg.conf.d/10-nvidia-force-1080p.conf，但还没生效；我 先确认文件内容和当前分辨率，再决定是否重启图形服务。 • 当前配置已经写好但还没生效。为了避免重启图形界面后黑屏，我会先放一个“自动回滚保护”：如果 60 秒内没有取 消，它会删除这份强制 1080p 配置并重启 GDM，把系统恢复到现在的 1600x900 路径。 • 我会把强制模式从单一 CVT 模式改成更接近 Windows 常用的 1080p CEA 时序，并保留 reduced-blanking 作为第二 选择。这样比只推 173 MHz 的 CVT 模式更稳，尤其你现在这条链路被识别成 VGA。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我刚把本地配置改成两种 1080p 时序：一个是更常见的 HDMI/CEA 148.5 MHz，另一个是 reduced blanking 138.5 MHz。现在我会把更新后的配置安装到系统目录，再准备一个带自动回滚的重启测试。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我会继续从当前状态推进：先把更新后的 1080p 配置同步到系统目录，然后创建一个自动回滚保护，再重启 GDM 让 Xorg 重新读配置。这个动作会中断当前桌面会话，但有回滚脚本兜底。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我已经有足够证据：当前 Xorg 会话不会读取新配置，只有重启 GDM/重启电脑才会让强制 1080p 生效。重启 GDM 会 退出当前桌面并关闭正在运行的图形应用，所以我不会悄悄执行；我会先把系统配置和回滚工具准备完整。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 为了提高成功率，我不会只靠 Modeline。更稳的做法是给 NVIDIA 一个“假的 1080p EDID”，让它像 Windows 一样认 为这个显示器明确支持 1920x1080。先检查系统里有没有生成 EDID 的工具。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我会继续推进，不只停在“写了配置”。下一步我准备生成一个 1080p 的 EDID 文件，让 NVIDIA 驱动启动时直接把当 前 VGA 类输出当作支持 1920x1080 的显示器，这通常比单纯强塞 Modeline 更稳。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我会安装 edid-decode 只用于校验生成的 EDID 是否有效；这不改变显示配置。然后把 EDID 文件放到 /etc/X11/ edid/1920x1080.bin，并让 NVIDIA 配置引用它。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • edid-decode 安装正在进行，我先等它完成。装完后我会生成并校验 1080p EDID，再把当前 NVIDIA 配置改成引用这 个 EDID。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我继续从当前状态接着做：edid-decode 已安装完成。现在我会生成一个最小但有效的 1080p EDID，并用工具校验校 验和和详细时序，确保 NVIDIA 启动时有可信的显示器能力信息。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我继续做“真正让系统识别 1080p”的方案。刚才发现系统目录里的配置还是旧版 173 MHz CVT 时序，本地文件已经改 成更稳的 148.5/138.5 MHz 两套时序；我会先把系统目录同步到新版，再加上伪 EDID。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我会从当前机器状态重新核对一次，避免用过期上下文继续改。重点看三件事：系统目录里的 Xorg 配置、当前分辨 率、以及可用的 EDID 工具。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 当前状态清楚了：系统仍是 1600x900，系统目录里的 Xorg 配置还是旧版；本地新版配置还没同步。现在我会先找系 统里是否已有通用 1080p EDID 固件，能复用就不手写二进制。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我会继续推进到可验证状态。现在已经确认系统没有现成 EDID 文件，我会生成一个标准 1080p EDID、校验它，再把 NVIDIA 配置改为引用这个 EDID；这比单纯塞 Modeline 更接近 Windows 的行为。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 下一步我会做两件事：先把系统配置同步成新版，然后生成并校验一个本地 1080p EDID 文件。完成后才重启图形服务 测试，因为这个动作会断开当前桌面会话。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我现在开始生成 EDID。这里不直接手写不可读的二进制，而是用结构化字节生成并立刻用 edid-decode 检查；如果校 验不通过，不会装进系统配置。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我会继续从当前状态推进，不假设前面已经成功。现在重点是生成一个可校验的 1080p EDID，然后把 NVIDIA 配置 从“强塞 Modeline”升级为“给驱动一个明确支持 1080p 的显示器信息”。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我会继续从“生成有效 EDID”这一步做，先不重启图形服务。重启是最后一步，因为它会让当前桌面会话退出；在那之 前我会把配置、EDID、回滚脚本都准备好并校验。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我会先生成 EDID 到桌面文件，然后用 edid-decode --check 验证。只有验证能解析出原生/首选 1920x1080，我才会 把它安装到 /etc/X11/edid/ 并引用到 Xorg 配置里。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 生成的 EDID 已经能被解析出原生 1920x1080，但校验发现一个问题：详细时序里的物理尺寸和 EDID 头部尺寸不一 致。我会修正这个字段，重新校验到 PASS 后再安装。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • EDID 已生成并通过校验：原生分辨率明确是 1920x1080，首选时序是 1920x1080_60.00，edid-decode 结果为 PASS。 下一步我会把这个 EDID 安装到系统目录，并更新 NVIDIA Xorg 配置引用它。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我会在本地配置副本里加入 CustomEDID，让 NVIDIA 驱动启动时读取这个 1080p EDID。然后再用 sudo install 同步 到 /etc/X11，保留桌面上的副本便于查看和回滚。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我已经把 CustomEDID 加进本地配置副本。接下来会把通过校验的 EDID 和新版配置安装到系统目录，并创建一个回滚 脚本；这一步不会重启桌面。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 配置和 EDID 已经安装好了，并且 EDID 校验通过：原生分辨率是 1920x1080。现在剩下的关键步骤是重启 GDM 让 Xorg 重新读取配置；我会先布置一个自动回滚保护，避免重启后黑屏无法进桌面。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 现在到了真正测试阶段。因为重启 GDM 会退出当前图形会话，我会先用 systemd-run 安排一个 90 秒自动回滚任务： 如果我没有确认成功，它会删除强制 1080p 配置并再次重启 GDM。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我先确认自动回滚任务有没有已经触发，以及强制 1080p 配置是否还在。上一阶段已经把可校验的 1080p EDID 和 Xorg 配置安装好了，剩下就是让 GDM 重新读取配置并验证。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我先接管一下前面留下的自动回滚任务，避免它在我们还没测试 GDM 重启前把配置删掉。然后我会重新安排一个更明 确的回滚窗口，再执行实际的显示服务重启测试。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我先取消前面 90 秒自动回滚任务，避免它在正式测试前把配置删掉。现在系统已经有可校验的 1080p EDID 和 Xorg 配置，下一步需要重启显示管理器才会生效。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我看到前一个自动回滚计时器还在等待触发，先把它真正停掉，避免它误删刚装好的 1080p 配置。然后我会重新安排 一个更长的安全回滚窗口，再做实际的 GDM 重启测试。 ■ Conversation interrupted - tell the model what to do differently. Something went wrong? Hit /feedback to report the issue. ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我先把当前状态重新核对一遍，因为前面有一个自动回滚计时器可能已经触发。重点看：配置文件是否还在、GDM 是否 重启过、当前 xrandr 是否已经出现或切到 1920x1080。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 自动回滚在 08:25:42 触发了，已经把系统目录里的 1080p 配置和 EDID 删除，并把 GDM 重启回当前 1600x900 状 态。桌面上的配置副本还在，所以我会重新安装它，这次不再放会提前误触发的回滚计时器。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我会重新安装桌面上已经校验过的 1080p EDID 和配置，然后用更可控的方式测试。前一个自动回滚已经确认生效并恢 复到了 1600x900，所以现在系统目录是干净状态。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我看到了一个关键细节：上一次启动日志只写了 Using system config directory “/usr/share/X11/xorg.conf.d”， 没有明显显示 /etc/X11/xorg.conf.d。所以我会重新安装配置后，优先确认 Xorg 是否真的读取这个目录；如果它不 读，我会改为完整 /etc/X11/xorg.conf 方案。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我先把配置重新装回系统目录，并确认 EDID 文件仍然是通过校验的版本。这一步不会重启图形界面。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 配置已经重新安装到系统目录，并且 EDID 文件校验通过，原生分辨率是 1920x1080。我现在先做一个非破坏性的校 验：确认 Xorg 会读取 /etc/X11/xorg.conf.d，以及配置语法没有明显问题；然后再决定是否重启图形服务。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 日志里有一个重要点：当前 Xorg 启动时没有读取 /etc/X11/xorg.conf.d 里的配置，因为当时配置已被自动回滚删掉 了。现在配置已经重新装回去，我会做一次真正的 GDM 重启测试，并把回滚窗口设长一点，避免再次提前误删。 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 我会用一个脚本执行：重新确认配置存在，安排 4 分钟后自动回滚，然后立刻重启 GDM。重启后我会轮询 xrandr 和 Xorg 日志；如果能正常进桌面，我会取消回滚，避免它再干扰测试结果。 ■ Conversation interrupted - tell the model what to do differently. Something went wrong? Hit /feedback to report the issue. MCP client for Chrome DevTools MCP failed to start: MCP startup failed: Invalid MCP server name ‘Chrome DevTools MCP’: must match pattern [2] +$ MCP startup incomplete (failed: Chrome DevTools MCP) • 我先重新接上当前机器状态，确认刚才被中断的测试脚本有没有重启过 GDM、有没有留下回滚计时器，以及现在系统目 录里的 1080p 配置是否还在。 • Ran xrandr --query | sed -n ‘1,60p’ └ Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384 DVI-I-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 810mm x 460mm … +53 lines (ctrl + t to view transcript) DP-1 disconnected (normal left inverted right x axis y axis) DVI-D-0 disconnected (normal left inverted right x axis y axis) • Ran ls -l /etc/X11/xorg.conf /etc/X11/xorg.conf.d/10-nvidia-force-1080p.conf /etc/X11/edid/ │ forced-1080p-edid.bin /home/bing521/桌面/10-nvidia-force-1080p.conf /home/bing521/桌面/ │ forced-1080p-edid.bin /tmp/codex-1080p-test.log /tmp/codex-xrandr-after-gdm.txt 2>/dev/null || true └ -rw-r–r-- 1 root root 128 Jun 10 09:04 /etc/X11/edid/forced-1080p-edid.bin -rw-r–r-- 1 root root 1345 Jun 10 09:04 /etc/X11/xorg.conf.d/10-nvidia-force-1080p.conf … +2 lines (ctrl + t to view transcript) -rw-rw-r-- 1 bing521 bing521 361 Jun 10 09:05 /tmp/codex-1080p-test.log -rw-rw-r-- 1 bing521 bing521 2421 Jun 10 09:05 /tmp/codex-xrandr-after-gdm.txt • Ran date ‘+%F %T %Z’; systemctl list-timers --all ‘codex-1080p*’ --no-pager 2>/dev/null || true; │ systemctl status codex-1080p-rollback.timer codex-1080p-rollback.service --no-pager 2>/dev/null | │ sed -n ‘1,140p’ || true └ 2026-06-10 09:07:57 CST NEXT LEFT LAST PASSED UNIT ACTIVATES … +22 lines (ctrl + t to view transcript) fi". Jun 10 08:25:43 bing521 systemd[1]: codex-1080p-rollback.service: Deactivated successfully. • Ran journalctl -b _COMM=Xorg --no-pager | rg -i ‘Using config|xorg.conf|xorg.conf.d|CustomEDID|forced| │ EDID|CRT-0|Validated MetaModes|Setting mode|No valid modes|1920|error|warning’ | tail -n 220 └ Jun 09 16:44:11 bing521 /usr/libexec/gdm-x-session[1633]: (WW) warning, (EE) error, (NI) not implemented, (??) unknown. … +96 lines (ctrl + t to view transcript) Jun 10 09:07:57 bing521 /usr/libexec/gdm-x-session[519779]: (–) NVIDIA(GPU-0): CXD Forced1080p (CRT-0): 400.0 MHz maximum pixel clock ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 现在关键结果已经出来了：xrandr 显示当前已经是 1920x1080，Xorg 日志也确认读取了伪 EDID 和强制配置。还有一 个自动回滚计时器挂着，我先把它取消，避免它把已经成功的配置删掉。 • Ran printf ‘%s\n’ ‘555999’ | sudo -S touch /run/codex-1080p-confirmed && printf ‘%s\n’ ‘555999’ | sudo │ -S systemctl stop codex-1080p-rollback.timer codex-1080p-rollback.service 2>/tmp/ │ codex-stop-final.err || true │ … +3 lines └ [sudo] password for bing521: NEXT LEFT LAST PASSED UNIT ACTIVATES 0 timers listed. • Ran ls -l /etc/X11/xorg.conf.d/10-nvidia-force-1080p.conf /etc/X11/edid/forced-1080p-edid.bin 2>/dev/ │ null || true └ -rw-r–r-- 1 root root 128 Jun 10 09:04 /etc/X11/edid/forced-1080p-edid.bin -rw-r–r-- 1 root root 1345 Jun 10 09:04 /etc/X11/xorg.conf.d/10-nvidia-force-1080p.conf • Ran xrandr --query | sed -n ‘1,18p’ └ Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384 DVI-I-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 810mm x 460mm … +14 lines (ctrl + t to view transcript) 1440x810 60.00 59.97 1400x1050 74.76 59.98 • Ran cat /run/codex-1080p-revert.log 2>/dev/null || true └ (no output) • Updated Plan └ 重新安装已校验的 1080p EDID 和 NVIDIA Xorg 配置 重启图形服务让配置生效 用 xrandr 和 Xorg 日志验证 1920x1080 是否可用 如果失败，改用完整 xorg.conf 或内核 EDID override 方案 ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 已经好了。当前系统已经切到并支持 1920x1080： current 1920 x 1080 DVI-I-0 connected primary 1920x1080 1920x1080 60.00*+ 我做的处理是： 生成了一个通过校验的 1080p EDID：/etc/X11/edid/forced-1080p-edid.bin 写入 NVIDIA/Xorg 配置：/etc/X11/xorg.conf.d/10-nvidia-force-1080p.conf 重启了 GDM 让配置生效 取消了自动回滚计时器，避免它删除配置 Xorg 日志也确认已经识别为 CXD Forced1080p，并设置了 1920x1080_60.00。目标已完成，用时约 24 分钟。 ─ Worked for 2m 30s ────────────────────────────────────────────────────────────────────────────────────── › 系统重启不会又变回去吧？ • 我快速确认一下持久化文件和回滚任务状态。只要配置文件还在 /etc/X11，重启后 Xorg 会继续读取它。 • Ran ls -l /etc/X11/xorg.conf.d/10-nvidia-force-1080p.conf /etc/X11/edid/forced-1080p-edid.bin 2>/dev/ │ null || true └ -rw-r–r-- 1 root root 128 Jun 10 09:04 /etc/X11/edid/forced-1080p-edid.bin -rw-r–r-- 1 root root 1345 Jun 10 09:04 /etc/X11/xorg.conf.d/10-nvidia-force-1080p.conf • Ran xrandr --query | sed -n ‘1,8p’ └ Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384 DVI-I-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 810mm x 460mm … +4 lines (ctrl + t to view transcript) 2560x1440 59.96 59.95 2048x1536 85.00 75.00 60.00 • Ran systemctl list-timers --all ‘codex-1080p*’ --no-pager 2>/dev/null || true └ NEXT LEFT LAST PASSED UNIT ACTIVATES 0 timers listed. ────────────────────────────────────────────────────────────────────────────────────────────────────────── • 不会。现在是持久化配置，不是临时 xrandr： 配置文件还在：/etc/X11/xorg.conf.d/10-nvidia-force-1080p.conf EDID 文件还在：/etc/X11/edid/forced-1080p-edid.bin 自动回滚计时器已取消：0 timers listed 当前仍是：1920x1080 60.00*+ 所以正常重启后还会按这个配置进入 1920x1080。如果以后换显示器或换线导致异常，删除上面两个文件再重启 GDM/ 系统即可恢复默认识别。 ─ Worked for 1m 09s ────────────────────────────────────────────────────────────────────────────────────── › Find and fix a bug in @filename gpt-5.5 xhigh · ~/桌面 Goal achieved (24m) 解决了我困扰已久的不能用1080P的问题，/goal是真的强大 a-zA-Z0-9_- ↩︎ a-zA-Z0-9_- ↩︎ 3 个帖子 - 2 位参与者 阅读完整话题
如题, 是不能使用CPA中转吗, 另外用chrome登录每日都提示需要清理cookies, 了解的佬友提点下,谢谢 6 个帖子 - 4 位参与者 阅读完整话题
谷歌推出 Chrome v149.0.7827.103 紧急安全更新，修复 1 个已经被黑客利用的安全漏洞，发现该漏洞的安全研究员获得 5.5 万美元的奖励。 目前只知道该漏洞属于 V8 引擎中的越界内存访问，但具体细节暂时还没有公布，只不过能获得 5.5 万美元奖金说明漏洞应该比较严重的。 https://www.landian.news/archives/113379.html 1 个帖子 - 1 位参与者 阅读完整话题
前言 最近我在开发一个基于 Plasmo 的 Chrome MV3 浏览器扩展，项目主要用于统一管理 ChatGPT、Claude 等 AI 平台的对话记录，支持账号同步、搜索、收藏、标签、批量操作等功能。 随着功能逐渐完善，扩展里出现了大量 UI 文案、提示信息、错误信息。如果这些文本全部硬编码在组件里，后续维护会非常麻烦： 想支持英文、中文等多语言时，需要到处改代码； popup、content script、background 里都有文案，容易遗漏； Chrome 扩展本身也有名称、描述等 manifest 文案，也需要国际化； 文案带变量时，比如“已选中 5 项”，如果手动拼接，会不利于多语言适配。 因此，我最终使用 Chrome 扩展原生提供的 chrome.i18n API，再结合 Plasmo 的目录约定，给项目做了一套轻量、简单、够用的国际化方案。 本文就结合我的项目实践，介绍如何在 Plasmo 浏览器扩展中实现 i18n。 一、项目技术栈 我的项目是一个 Chrome MV3 扩展，主要技术栈如下： Plasmo React TypeScript Tailwind CSS Chrome Extension Manifest V3 项目结构比较简单，所有源文件都放在项目根目录，没有额外的 src 目录。 核心文件大致如下： my-first-extension/ ├── popup.tsx ├── content.ts ├── background.ts ├── logic.ts ├── db.ts ├── utils/ │ └── i18n.ts ├── locales/ │ ├── en/ │ │ └── messages.json │ └── zh_CN/ │ └── messages.json ├── package.json └── ... 其中和国际化相关的主要是： utils/i18n.ts locales/en/messages.json locales/zh_CN/messages.json package.json 二、Plasmo 项目中的语言包目录 在 Chrome 扩展规范中，最终构建产物里通常会有 _locales 目录，例如： _locales/ ├── en/ │ └── messages.json └── zh_CN/ └── messages.json 而在 Plasmo 项目开发阶段，我们可以直接在项目中创建： locales/ ├── en/ │ └── messages.json └── zh_CN/ └── messages.json Plasmo 构建时会处理这些语言资源，让它们符合 Chrome Extension 的国际化规范。 我的项目里目前支持两种语言： locales/en/messages.json locales/zh_CN/messages.json 其中： en 是英文； zh_CN 是简体中文。 三、在 manifest 中配置默认语言 Chrome 扩展要启用国际化，必须在 manifest 中声明 default_locale 。 在 Plasmo 项目里，可以直接在 package.json 的 manifest 字段里配置： { "manifest": { "default_locale": "en", "permissions": [ "storage", "alarms" ], "host_permissions": [ "https://chatgpt.com/*", "https://claude.ai/*" ] } } 这里我把默认语言设置为英文： "default_locale": "en" 这意味着如果用户当前浏览器语言没有对应的语言包，Chrome 会回退使用英文语言包。 四、扩展名称和描述的国际化 浏览器扩展的名称、描述也可以使用 Chrome i18n 的占位符语法。 我的 package.json 中这样写： { "name": "multi-ai-conversation-manager", "displayName": "__MSG_extName__", "description": "__MSG_extDescription__" } 这里的重点是： "displayName": "__MSG_extName__", "description": "__MSG_extDescription__" __MSG_xxx__ 是 Chrome 扩展国际化的特殊语法。 例如： __MSG_extName__ 会去当前语言包的 messages.json 中查找： { "extName": { "message": "ChatGPT & Claude AI Conversation Manager" } } 中文语言包中对应的是： { "extName": { "message": "ChatGPT、Claude AI 对话管理器" } } 这样一来，扩展在 Chrome 扩展管理页、商店信息或者 manifest 中展示时，就能根据用户浏览器语言自动切换名称和描述。 五、messages.json 的基本格式 Chrome 扩展的语言文件必须叫做 messages.json 。 基本格式如下： { "key": { "message": "具体文案" } } 比如英文语言包： { "account_management": { "message": "Account Management" }, "account_add": { "message": "Add Account" }, "btn_confirm": { "message": "Confirm" }, "btn_cancel": { "message": "Cancel" } } 中文语言包： { "account_management": { "message": "账号管理" }, "account_add": { "message": "添加账号" }, "btn_confirm": { "message": "确认" }, "btn_cancel": { "message": "取消" } } 这里需要注意： 不同语言包里的 key 要保持一致。 也就是说，英文里有： "account_add" 中文里也必须有： "account_add" 否则运行时调用这个 key 时，某些语言环境下就可能取不到翻译。 六、封装一个统一的 t 函数 虽然可以在代码里直接写： chrome.i18n.getMessage("btn_confirm") 但如果项目中大量使用这个 API，会有几个问题： 写起来比较长； 后续如果想增加 fallback 逻辑，需要到处改； popup、content script、background 都会重复使用； 不方便统一处理参数替换。 所以我在项目中封装了一个简单的工具函数。 文件位置： utils/i18n.ts 代码如下： /** * Chrome 扩展国际化工具函数 * 封装 chrome.i18n API，提供类型安全的文本获取方法 */ /** * 获取国际化文本 * @param key - messages.json 中定义的 key * @param substitutions - 可选的替换参数，字符串或字符串数组 * @returns 翻译后的文本，如果 key 不存在则返回 key 本身 */ export function t(key: string, substitutions?: string | string[]): string { return chrome.i18n.getMessage(key, substitutions) || key } 这个函数做了两件事： 第一，简化调用： t("btn_confirm") 比下面这样更简洁： chrome.i18n.getMessage("btn_confirm") 第二，增加 fallback： return chrome.i18n.getMessage(key, substitutions) || key 如果某个 key 没有找到，直接返回 key 本身。这样至少页面不会显示空字符串，调试时也很容易发现哪个 key 没配置。 七、在 React Popup 页面中使用 i18n 我的扩展主要 UI 在 popup.tsx 中，它是一个 React 页面。 首先引入工具函数： import { t } from "./utils/i18n" 然后就可以在 JSX 中使用： <button> {t("account_add")} </button> 或者用于错误提示： return ( <div className="p-4 text-red-500 text-sm"> {t("errorBoundaryMessage")} </div> ) 对应的英文语言包： { "errorBoundaryMessage": { "message": "An error occurred. Please close and reopen the extension" } } 对应的中文语言包： { "errorBoundaryMessage": { "message": "出现错误，请关闭后重新打开扩展" } } 这样，当用户浏览器语言是中文时，会显示中文；如果是英文环境，则显示英文。 八、在 Content Script 中使用 i18n 浏览器扩展不仅 popup 页面需要国际化，content script 也经常需要显示文案。 我的项目中， content.ts 会注入到 ChatGPT 或 Claude 页面中，用于检测当前登录账号。如果发现新账号，会在页面右下角显示一个提示卡片，引导用户同步账号。 同样先引入： import { t } from "./utils/i18n" 然后在创建 DOM 时使用： card.innerHTML = ` <button class="close-btn" aria-label="${t('content_closeAriaLabel')}">×</button> <div class="header"> <div class="text-content"> <h3>${t('content_newAccountTitle')}</h3> <p>${t('content_newAccountDesc', platformName)}</p> </div> </div> <div class="actions"> <button class="btn-ignore">${t('content_btnIgnore')}</button> <button class="btn-add">${t('content_btnSync')}</button> </div> ` 这里有一个带变量的文案： t("content_newAccountDesc", platformName) 比如英文里可能是： { "content_newAccountDesc": { "message": "A new $PLATFORM$ account was detected. Do you want to sync it now?", "placeholders": { "platform": { "content": "$1", "example": "ChatGPT" } } } } 中文里可以是： { "content_newAccountDesc": { "message": "检测到新的 $PLATFORM$ 账号，是否立即同步？", "placeholders": { "platform": { "content": "$1", "example": "ChatGPT" } } } } 这样在代码里只需要传入平台名称： t("content_newAccountDesc", "ChatGPT") 最终 Chrome 会自动把 $1 对应的内容替换进去。 九、在 Background 和业务逻辑中使用 i18n 除了 UI，后台逻辑里也会产生提示信息或错误信息。 比如消息处理器、同步逻辑、错误封装中，也可以统一使用： import { t } from "~utils/i18n" 或： import { t } from "./utils/i18n" 然后： throw new Error(t("error_accountMismatch")) 或者： return { success: false, error: t("error_syncFailed") } 这样有一个好处： 前端展示的错误信息和后台返回的错误信息，都可以使用同一套语言包管理。 对于浏览器扩展来说，popup、content script、background 是不同运行环境，如果不统一管理文案，后期维护会很痛苦。 十、带参数文案的写法 国际化里最常见的问题之一，就是文案里带变量。 比如： 已选中 5 项 不能简单写成： "已选中 " + count + " 项" 因为不同语言的语序可能不一样。 正确做法是放到语言包中： 英文： { "batch_selectedCount": { "message": "$COUNT$ items selected", "placeholders": { "count": { "content": "$1", "example": "5" } } } } 中文： { "batch_selectedCount": { "message": "已选中 $COUNT$ 项", "placeholders": { "count": { "content": "$1", "example": "5" } } } } 代码中调用： t("batch_selectedCount", String(selectedCount)) 如果有多个参数，也可以传数组： t("error_accountMismatch", [oldEmail, newEmail]) 语言包中可以使用： { "error_accountMismatch": { "message": "账号不匹配：当前账号是 $CURRENT$，目标账号是 $TARGET$", "placeholders": { "current": { "content": "$1", "example": "[email protected]" }, "target": { "content": "$2", "example": "[email protected]" } } } } 十一、推荐的 key 命名方式 随着项目变大，语言包会越来越长。如果 key 命名不规范，很容易混乱。 我在项目中采用了按业务模块前缀命名的方式，例如： theme_light theme_dark theme_system account_management account_add account_delete account_sync batch_manage batch_addTag batch_removeTag batch_selectedCount tag_management tag_create tag_rename tag_delete conversation_notFound conversation_total conversation_copyLink content_newAccountTitle content_newAccountDesc content_btnIgnore content_btnSync errorBoundaryMessage error_syncFailed 这种命名方式有几个优点： 一眼能看出文案属于哪个模块； 搜索方便； 不容易和其他模块冲突； 语言包比较容易维护。 我个人不太建议全部写成非常短的 key，例如： title desc button message 因为项目一大，这些 key 很快就会失去语义。 十二、Chrome i18n 的语言选择机制 使用 chrome.i18n 后，不需要我们自己判断用户语言。 Chrome 会根据用户浏览器语言自动选择语言包。 比如项目里有： locales/en/messages.json locales/zh_CN/messages.json 如果用户浏览器语言是中文简体，Chrome 会优先使用： zh_CN 如果用户浏览器语言是英文，则使用： en 如果没有找到对应语言，会回退到 manifest 中配置的： "default_locale": "en" 所以在大多数情况下，我们不需要自己写： navigator.language 也不需要自己维护语言切换逻辑。 十三、Plasmo i18n 实现流程总结 整体流程可以总结为五步。 1. 创建语言包目录 locales/ ├── en/ │ └── messages.json └── zh_CN/ └── messages.json 2. 在 package.json 中配置默认语言 { "manifest": { "default_locale": "en" } } 3. 使用 __MSG_xxx__ 国际化扩展名称和描述 { "displayName": "__MSG_extName__", "description": "__MSG_extDescription__" } 4. 封装 i18n 工具函数 export function t(key: string, substitutions?: string | string[]): string { return chrome.i18n.getMessage(key, substitutions) || key } 5. 在 popup、content script、background 中统一调用 t("btn_confirm") t("batch_selectedCount", String(count)) t("content_newAccountDesc", platformName) 十四、这种方案的优点 我目前这个项目采用的是原生 chrome.i18n 方案，而不是引入 i18next 、 react-intl 之类的第三方库。 原因很简单：对于浏览器扩展来说，原生方案已经足够好用。 它的优点包括： 1. 不需要额外依赖 不需要安装额外 npm 包，减少 bundle 体积。 2. 和 Chrome 扩展天然集成 manifest 中的名称、描述都可以直接使用 __MSG_xxx__ 。 3. popup、content script、background 都能用 只要在扩展环境中，都可以调用： chrome.i18n.getMessage() 4. 构建简单 Plasmo 会处理扩展构建，不需要自己手动生成 _locales 。 5. 维护成本低 对于中小型浏览器扩展项目，这种方案非常轻量。 十五、需要注意的坑 1. 必须配置 default_locale 如果使用了语言包，但是 manifest 没有配置： "default_locale": "en" 扩展可能无法正确加载国际化资源。 2. key 必须在所有语言包中保持一致 比如英文有： "btn_confirm" 中文也应该有： "btn_confirm" 否则在某些语言下会取不到翻译。 3. messages.json 格式不能随便写 Chrome i18n 不是普通 JSON 字典，不能写成： { "btn_confirm": "Confirm" } 必须写成： { "btn_confirm": { "message": "Confirm" } } 4. 占位符要用 $1 、 $2 比如： { "conversation_total": { "message": "$COUNT$ conversations", "placeholders": { "count": { "content": "$1", "example": "10" } } } } 代码中： t("conversation_total", "10") 5. 不建议在代码里拼接多语言句子 不推荐： t("selected") + count + t("items") 推荐： t("batch_selectedCount", String(count)) 因为不同语言的语序可能不一样。 6. content script 中使用 innerHTML 时要注意安全 如果语言包内容完全由开发者自己维护，风险较小。但如果文案来自用户输入，就不要直接拼进 innerHTML 。 我的项目中的语言包是静态文件，由开发者维护，所以可以用于构造提示卡片。但如果要插入用户输入，最好使用 textContent 或做好转义。 十六、适合继续优化的方向 目前这个方案已经可以满足我的项目需求，不过后续还可以继续优化。 1. 给 key 增加 TypeScript 类型约束 现在的 t 函数是： export function t(key: string, substitutions?: string | string[]): string 也就是说 key 是普通字符串。 如果写错了： t("btn_confim") TypeScript 不会报错，只有运行时才会发现。 后续可以自动从 messages.json 生成类型，例如： type I18nKey = | "btn_confirm" | "btn_cancel" | "account_add" | "account_delete" 然后改成： export function t(key: I18nKey, substitutions?: string | string[]): string { return chrome.i18n.getMessage(key, substitutions) || key } 这样可以在开发阶段提前发现 key 拼写错误。 2. 编写脚本检查多语言 key 是否一致 可以写一个 Node.js 脚本，对比： locales/en/messages.json locales/zh_CN/messages.json 检查两个文件的 key 是否完全一致。 比如： en 中有但 zh_CN 中没有 zh_CN 中有但 en 中没有 这对项目变大后非常有用。 3. 拆分语言包 当 messages.json 变得非常大时，可以按模块维护源文件，例如： i18n-source/ ├── account.json ├── batch.json ├── tag.json ├── content.json └── error.json 然后通过脚本合并生成最终的： locales/en/messages.json locales/zh_CN/messages.json 不过对于大多数浏览器扩展项目，一个 messages.json 也完全够用。 十七、完整示例 下面给一个简化版完整示例。 package.json { "name": "multi-ai-conversation-manager", "displayName": "__MSG_extName__", "description": "__MSG_extDescription__", "manifest": { "default_locale": "en", "permissions": [ "storage", "alarms" ] } } locales/en/messages.json { "extName": { "message": "ChatGPT & Claude AI Conversation Manager" }, "extDescription": { "message": "Unified management for ChatGPT and Claude conversations" }, "btn_confirm": { "message": "Confirm" }, "btn_cancel": { "message": "Cancel" }, "batch_selectedCount": { "message": "$COUNT$ items selected", "placeholders": { "count": { "content": "$1", "example": "5" } } } } locales/zh_CN/messages.json { "extName": { "message": "ChatGPT、Claude AI 对话管理器" }, "extDescription": { "message": "统一管理 ChatGPT、Claude 平台的 AI 对话" }, "btn_confirm": { "message": "确认" }, "btn_cancel": { "message": "取消" }, "batch_selectedCount": { "message": "已选中 $COUNT$ 项", "placeholders": { "count": { "content": "$1", "example": "5" } } } } utils/i18n.ts export function t(key: string, substitutions?: string | string[]): string { return chrome.i18n.getMessage(key, substitutions) || key } popup.tsx import { t } from "./utils/i18n" export default function Popup() { const selectedCount = 5 return ( <div> <button>{t("btn_confirm")}</button> <button>{t("btn_cancel")}</button> <p>{t("batch_selectedCount", String(selectedCount))}</p> </div> ) } 结语 在 Plasmo 浏览器扩展项目中实现 i18n，并不一定要引入复杂的国际化框架。 对于大多数 Chrome 扩展来说，直接使用浏览器原生的 chrome.i18n API 就已经足够： manifest 文案使用 __MSG_xxx__ ； 页面和脚本中使用 chrome.i18n.getMessage() ； 封装一个简单的 t() 函数； 使用 locales/en/messages.json 、 locales/zh_CN/messages.json 管理语言包； 对变量文案使用 placeholders。 这种方式简单、轻量、和浏览器扩展生态天然兼容，非常适合 Plasmo 架构下的扩展开发。 我目前的项目就是采用这种方案，同时覆盖了 popup 页面、content script、background 消息处理和错误提示。整体使用下来，维护成本低，也方便后续继续增加更多语言支持。 1 个帖子 - 1 位参与者 阅读完整话题
之前用edge登录是可以的，chrome不行。现在用edge也不让登录了，但是写着可以用edge登录。家里人用电脑，发现不能用了，下了个360安全浏览器，虽然没广告和捆绑，但是就是强迫症不想留多余的浏览器，工行网银助手我也下了，也没用 1 个帖子 - 1 位参与者 阅读完整话题
🌐 English | 中文 🪶 飞书文档 AI 助手 用一句话操作飞书文档 / 多维表格 / 电子表格的 Chrome 侧边栏 AI 助手 Feishu Document AI Assistant — operate Docs / Base / Sheet in natural language, from a side panel. 用自然语言经 AI 直接操作**飞书多维表格(Base) / 电子表格(Sheet) / 文档(Docs)**—— 建表、填数、写公式、生成文档、按评论改稿、跨表查找、去重、审计，一句话搞定。 🤖 AI ：OpenAI 兼容接口，默认中国大模型（ DeepSeek ），模型 / Key / Base URL 运行时可配。 🧩 形态 ：侧边栏 + 注入飞书页的内容脚本 + 后台 Service Worker 。运行时依赖仅 React + openai SDK ， 无后端 。 🔒 安全优先 ：助手始终以 用户本人身份 操作、绝不越权；所有权限边界 硬编码在代码里 （提示词不作安全边界）。 🎬 演示 ▶️ YouTube 观看 · 打不开 YouTube ？ 下载本地演示 mp4 📚 完整文档 → docs/PROJECT.md （架构 / 功能 / 安全 / 部署 / 配置一站式） · 部署指南（企业/个人/私有化快速上手） docs/DEPLOYMENT.md · 使用手册（含截图） docs/USER_GUIDE.md · 模块细节 ARCHITECTURE.md · 安全审计 SECURITY_AUDIT.md · 企业 MDM 强制安装 docs/enterprise/DEPLOY.md 🚀 个人快速上手（ 5 步） 完整版（每个权限的说明、加密模式、排错）见 docs/QUICKSTART.md 。 配飞书应用 （ open.feishu.cn → 创建企业自建应用）：记下 App ID / Secret ；「权限管理」开通 offline_access （必须）+ 按需 bitable:app docx:document sheets:spreadsheet drive:drive wiki:wiki contact:user.base:readonly （ 都勾「用户身份」 ）；「重定向 URL 」加 https://jhdbgegkmhcopcilclkpioilclemkeog.chromiumapp.org/ ；把自己加进「可用范围」并 发布 。 填配置 ： cp .env.example .env.local → 填 VITE_FEISHU_APP_ID + VITE_FEISHU_APP_SECRET （或 node scripts/encrypt-secret.mjs 出密文填 VITE_FEISHU_APP_SECRET_ENC 、明文留空）。 一键打包 ： npm install && npm run pack （产出 dist/ 与 feishu-doc-ai-assistant.zip ）。 加载 ： chrome://extensions → 开发者模式 → 「加载已解压」→ 选 dist/ 。 用 ：打开飞书 多维表格/文档 → 侧边栏 → 设置里「飞书授权」+ 填大模型 Key →（加密模式先输解锁密码）→ 一句话开干。 功能 AI 对话操作 ：~50 个工具覆盖多维表格(建/改表、字段、视图、记录增改删、结构化搜索)、 电子表格(读写区间、填列、查找替换、行列增删)、文档(Markdown 转文档、插入各类内容块、按评论改稿)。 复合能力 ：去重 / 跨表查找 / 条件批量更新 / 表→表汇总 / 审计（带原子性与部分失败上报）。 通用 API ：覆盖不到的需求按官方文档自造请求—— 默认拒绝白名单 严格限制。 场景模板 ：内置 CRM / 电商 / 项目管理，可配远程模板库，一键建库（表结构 + 示例数据 + 仪表盘）。 越用越聪明 ：每次成功后把「下次怎么做最稳」用模型 提炼成一条经验 存在 本机 （最多 300 条、只存做法不存数据）， 下次相似任务自动参考、少走弯路；重复任务只累计次数不重复消耗，可关闭/清空。 Auto 模式 ：自动确认文档内的内容删除（文件级删除始终硬拦）； 语音输入 🎤（公网构建，zh-CN ）。 网页剪藏 📎：在任意网页右键 / 快捷键，把选中内容或整页表格 AI 整理后写入飞书多维表格 / 电子表格 / 文档 ；也可拖入 CSV 文件导入。 仅在你 手势触发 时读取 当前页 DOM （ activeTab ，本地、无新增出站、无需放开 host_permissions ）；发送前先 预览 。 AI 小程序 🧩：一句话把当前表做成飞书页面上的悬浮窗小程序（可拖拽/四角缩放）—— 图表看板 (ECharts) / 计算器·交互工具 / 可打印报表 (window.print) / 汇报幻灯片 / 卡片墙·时间线等自定义视图 。 生成代码与数据 分离 ——保存后下次用 最新数据 一键打开、零 LLM ；一页可挂多个独立小程序（各自浮标）； 代码跑在 MV3 沙箱 （ null 源、 connect-src 'none' ）里 只读渲染 ， 拿了数据也发不出去 。详见 ARCHITECTURE.md 。 AI 建站 🌐：一句话（可附 参考站点 URL 作风格提示）把当前表做成一个 完整的网站页面 （导航 / 英雄区 / 指标卡 / 明细表）， 渲染成页面浮窗。沙箱里 预置了一套设计系统 ——即使描述很简略也能生成 好看、统一、符合插件风格 的页面； 离线自包含 （系统字体、无外链/CDN ）、数据绑定（重开拉最新数据）、可先出方案确认、可用语言微调、可保存。 AI 智能填充 🪄：在 多维表格 / 电子表格 里选一列，AI 参考同行其它列（和你已填好的示例）推断该列 空缺 的值—— 自动分类 / 打标签 / 归类 / 补全。 预览每一处再写回 ；单选/多选只会落到 已有选项 （绝不新建），数字/日期解析失败即跳过； 仅 更新 、以用户身份、只动当前表（默认只填空白格）；写入数 按飞书实际确认计数 ，不会虚报。 数据分析报告 📈：读当前 多维表格 / 电子表格 的数据，本地先算统计摘要，AI 写一篇 带真实数字 的分析报告 （摘要 / 关键发现 / 趋势异常 / 建议），生成飞书 文档 并在文末附上源数据表。飞书有「引用」但没有 AI 数据叙事——这是结合表格 + 文档写入的闭环。 文档体检 🩺：通读当前文档，AI 找出 逻辑断点 / 未定义术语 / 前后矛盾 / 遗留 TODO / 过期数据 / 空小节 ， 给出按严重度排序、可定位的问题清单（只读、不改文档）。文档版的 auditTable ，飞书无系统化审稿。 检查项可直接点开编辑、本机持久化 ——你定义体检什么。 文档总结 📝：通读当前文档，按你的要求生成总结（摘要 / 要点 / 待办…），可复制。 总结要求（ prompt ）可直接编辑、本机持久化 ——飞书原生 AI 速览是固定的，这里你说了算。 三种部署 ：个人 / 企业 SaaS / 私有化（ on-prem ），全部构建时配置切换。 快速开始（开发） npm install cp .env.example .env.local # 按需填写（见下方「配置」），可全空先跑通 npm run build # 产物 dist/ # chrome://extensions → 开发者模式 → 「加载已解压的扩展程序」→ 选 dist/ 开发与质量： npm run dev:ext # 扩展热更新（加载到 Chrome ） npm run dev:ui # 纯 UI 预览（ mock chrome ，不连飞书） npm run typecheck && npm run test 企业内部分发（不上架商店、不用开发者模式）见 docs/enterprise/DEPLOY.md ： 用项目脚本打 .crx + Chrome 策略强制安装（含现成 macOS .mobileconfig ）。 配置（全部可选，见 .env.example ） 运行时 （侧边栏 → 设置）：大模型供应商 / Base URL / API Key / 模型；飞书账号授权；强调色； 模板库地址；「越用越聪明」开关。 构建时 （ .env.local ，决定部署形态）： 变量 作用 VITE_FEISHU_APP_ID 飞书 App ID VITE_FEISHU_APP_SECRET 明文 secret （个人·明文，会进包） VITE_FEISHU_APP_SECRET_ENC 密码加密的 secret （个人·加密， scripts/encrypt-secret.mjs 生成） VITE_OAUTH_PROXY_URL OAuth 代理地址（企业/私有化，secret 不进包，见 docs/oauth-proxy-worker.js ） VITE_FEISHU_BASE_DOMAIN 飞书基础域名后缀，默认 feishu.cn ；私有化填内网域名（派生 open.<域名> 等） VITE_OPENAI_ALLOWED_HOSTS 大模型 host 白名单（设了则 CSP 也锁死 → 纯内网） VITE_ALLOWED_CIDRS 设备内网 CIDR 门 VITE_MAX_TOOL_CALLS 单轮工具调用上限（默认 30 ） VITE_CLIP_ENABLED 网页剪藏开关（默认开；设 false 不带剪藏功能） 安全设计（要点） 助手 以用户本人 user_access_token 操作 ，权限边界全部代码强制： 身份不超用户 ：用户读不了的文档 AI 也读不了；不回退应用(tenant)身份。 禁文件级删除 ：绝不删整表/电子表格/文档/云文件；内容级删除需按钮确认。 防注入 ：通用 API 默认拒绝白名单 + 硬阻断消息/通讯录/权限/所有权。 凭据保护 ：storage 内 AES-256-GCM ； App Secret 支持明文 / 密码加密 / 代理三档。 出站锁定 ：只访问飞书 + 大模型两类端点（代码层白名单 + CSP 双重，私有化可纯内网）。 逐条见 SECURITY_AUDIT.md 。 想给自己的组织打包？（ fork / 自建） 本仓库 manifest.json 的 key 与 extension-key.pem （已 gitignore ）固定了 作者的 扩展 ID 。 自建分发时请 生成你自己的签名密钥 并替换： # 1) 生成你自己的私钥 openssl genrsa 2048 > my-extension-key.pem # 2) 取它的公钥(base64 DER) 替换 manifest.json 的 "key" 字段 openssl rsa -in my-extension-key.pem -pubout -outform DER | openssl base64 -A # 3) 用你的私钥打 .crx （见 docs/enterprise/DEPLOY.md ） 这样你拥有独立的扩展 ID 与签名权，能自行平滑更新。 切勿提交任何 *.pem / .env.local / 解锁密码到仓库 （已在 .gitignore ）。 文档导航 文档 内容 docs/QUICKSTART.md 个人快速部署 ：配飞书应用权限 → 填配置 → npm run pack 一键打包 → 加载使用（ 5 步） docs/STORE_PUBLISHING.md 上架 Chrome 商店 ：零凭据公开版构建 + 用户自带应用首配 + 上架清单 + 审核风险规避 PRIVACY.md 隐私政策 （中英）：上架必填的隐私权 URL ，可直接托管使用 docs/DEPLOYMENT.md 部署指南 ：企业 / 个人 / 私有化快速上手（选路 + 命令 + 变量速查） docs/PRIVATE_DEPLOYMENT.md 私有化专用 ：内网/私有化飞书完整方案（出站锁定 / 代理 / 版本回退 / 验证清单） docs/USER_GUIDE.md 使用手册 ：全功能图文说明（含截图） docs/FAQ.md 常见问题 ：鉴权/导出/升级/私有化 排错 CLAUDE.md · docs/DEVELOPMENT.md 开发手册 ：面向 agent 的快速迭代（循环 / 仓库地图 / 硬约束 / 地雷区） docs/PROJECT.md 一站式 ：架构 / 功能 / 安全 / 部署 / 配置 ARCHITECTURE.md 深水区：模块结构、工具清单、字段类型、API 实测坑、模板引擎内部 SECURITY_AUDIT.md 安全设计逐条审计 + 攻击场景 + 修复（含 App Secret/OAuth 图解） docs/enterprise/DEPLOY.md 企业内部分发（.crx + Chrome 策略强制安装，含 macOS .mobileconfig ） docs/oauth-proxy/ · docs/oauth-proxy-server.mjs OAuth 代理：自托管 Node （ Docker/nginx ）+ Cloudflare 版，secret 不进包 .env.example 全部构建时配置项 CHANGELOG.md 版本更新日志 贡献 欢迎 Issue / PR 。提交前请跑通： npm run typecheck && npm run test && npm run build 改动若涉及安全卡点（ isFileLevelDelete / assertApiCallAllowed / resolveToken / assertSafeBaseUrl 等），请同步更新 SECURITY_AUDIT.md 与对应单测。 切勿提交任何密钥 / 密码 / 私钥 （ .gitignore 已覆盖 *.pem / *password*.txt / .env.* 等）。 ⚠️ 免责声明 本工具通过大模型对你的飞书数据执行真实操作（建表、写入、删除内容等）。虽然内置了 「文件级删除一律拒绝」「内容删除需确认」「以用户本人权限操作」等多重护栏， 仍建议在重要数据上 谨慎使用、必要时先备份 。开启「 Auto 模式」会跳过内容删除的逐次确认，请知悉风险。 作者不对因使用本工具造成的数据损失负责（详见 LICENSE ）。 许可证 Elastic License 2.0 © 2026 scott987-cmd — 源代码可见 （非 OSI 严格意义的"开源"；与 Elasticsearch 同款协议）。 一句话（以 LICENSE 原文为准）： 个人 / 企业均可免费使用、复制、修改、分发、自行部署（含公司内部商用）； 唯独禁止「把它作为托管 / SaaS 服务提供给第三方」 ，且不得绕过授权功能、不得去除版权/许可标识。 商业授权 需要「作为托管 / SaaS 服务对外提供」等受限用途授权？ 请在本仓库 GitHub Issues 开一个标注 commercial 的 issue （说明用途与规模）联系作者 scott987-cmd 洽谈。 🍴 Fork / 二次分发：必须替换 manifest.json 的 key （换成你自己的扩展 ID/签名私钥）并改掉文档中的扩展 ID / 重定向 / ALLOW_ORIGIN 占位，详见 docs/DEPLOYMENT.md §5 。
如题，使用codex，mcp布置了fetch，github，computeruse，Chrome，playwright，tavily，一看这么多搜索相关。问问tavily比起他内置的搜索有啥优势吗？我只知道computeruse的浏览器总是他说被url拦住，而且干啥都慢慢的，是不是需要啥skill？Chrome还算好用。playwrghit是不是可以删掉了？fetch好像常用，但我装的搜索过多了，怎么舍弃？问问大佬们搜索都是怎么配置的 2 个帖子 - 2 位参与者 阅读完整话题
一直在用L站拓展收藏插件 【开源自荐】LinuxDoStar: 为 L 站拓展收藏能力的chrome 浏览器插件 ，非常好用，除了常见的收藏帖子、收藏夹分类功能，还支持 收藏评论和云同步 。 但是原项目仅支持 Chrome 扩展，最近换了mac，safari用的比较多，所以在它的基础上vibe了 油猴版 ，并且新增了 拖拽 功能，在此分享给大家。 基本功能： 收藏帖子、评论 收藏夹分类 通过GitHub进行云同步 新增功能： 常驻收藏悬浮，快速打开收藏夹 拖拽功能，快速给收藏夹、收藏内容排序，快速移动收藏到其他收藏夹 修复了删除收藏后，点击同步又会将已删除的收藏同步回来的bug 安装链接： LinuxDo Star 实际效果： 收藏帖子、评论： 收藏界面： vibe coding完成，可能会有小问题，欢迎提出 非常感谢 codedogQBY 佬的开源，原贴链接 【开源自荐】LinuxDoStar: 为 L 站拓展收藏能力的chrome 浏览器插件 1 个帖子 - 1 位参与者 阅读完整话题
一直想要一个极简 的 chrome 插件， 能像 IE 那样的简单又纯粹的代理插件，之前做了一个简单的版本一直本地自己使用，现在终于优化后上线了市场 https://chromewebstore.google.com/detail/achpldjfbofjdiacdecldejnocakjimd?utm_source=item-share-cb 欢迎品鉴，感谢提供新的想法和建议