fix(website): 临时修复些小问题和不太顺眼的地方#658
Conversation
- 在「您的设备应该是」和 `platformName` 之间增加空格 - 修复 `x86_64` 被误判为 `x86` - 修复 `.AppImage` 大小写问题
因为我觉得这么做更合适，title 处应该写明**这是什么**而不是哪些系统能安装
Summary of ChangesHello @MoYingJi, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! 本次拉取请求主要针对网站下载页面进行了一系列优化和问题修复。核心目标是提升用户体验和数据准确性，包括修正了架构识别错误、解决了文件大小写兼容性问题，并对页面布局和文本显示进行了微调，使得下载信息更加清晰和易读。 Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
您好，感谢您的贡献！这次的 PR 修复了几个重要的小问题，特别是 x86_64 架构的识别错误和 .AppImage 的大小写问题，并优化了一些显示细节，提升了用户体验。
代码的修改方向是正确的。我主要有两个建议：
- 为了提高代码的健壮性，建议对
.AppImage文件后缀的检查改为不区分大小写的方式。 - 为了提升代码的可维护性，建议将多处重复的架构检测逻辑（如 x64, ARM64 等）提取为独立的辅助函数。
具体的修改建议请见我的评论。总体来说，这是一次很棒的修复和优化！
| const n = name.toLowerCase(); | ||
| const isArmAsset = n.includes("arm64") || n.includes("aarch64"); | ||
| const is32BitAsset = n.includes("ia32") || n.includes("x86"); | ||
| const is32BitAsset = n.includes("ia32") || (n.includes("x86") && !n.includes("x86_64")); |
There was a problem hiding this comment.
这个架构检查逻辑修复了 x86_64 被错误识别为32位的问题，做得很好。不过，我注意到类似的架构检测逻辑（如 ARM64、x64）散布在 getArchDisplay、sortAssets 和 isArchCompatible 等多个函数中。
为了提高代码的可维护性并避免重复，可以考虑将这些检测逻辑提取为独立的辅助函数，例如 isArmAsset, isX64Asset, is32BitAsset。这样可以让代码更清晰，也更容易在未来进行修改。
| } else if (p === "linux") { | ||
| const appImage = assets.find( | ||
| (f) => f.name.toLowerCase().endsWith(".appimage") && isArchCompatible(f.name, arch), | ||
| (f) => f.name.endsWith(".AppImage") && isArchCompatible(f.name, arch), |
There was a problem hiding this comment.
使用 endsWith('.AppImage') 会进行区分大小写的比较。虽然目前发布的文件名可能是固定的，但为了增加代码的健壮性，建议使用不区分大小写的匹配方式，以防未来文件名大小写发生变化。
可以考虑使用正则表达式，这与文件中其他地方（如369行）的做法一致。
(f) => /\.appimage$/i.test(f.name) && isArchCompatible(f.name, arch),
| assets: sortAssets(rawAssets.filter((f) => f.name.endsWith(".appimage"))), | ||
| title: "AppImage", | ||
| desc: "通用运行包", | ||
| assets: sortAssets(rawAssets.filter((f) => f.name.endsWith(".AppImage"))), |
There was a problem hiding this comment.
同样，这里也建议使用不区分大小写的匹配方式来查找 .AppImage 文件，以提高代码的健壮性。
assets: sortAssets(rawAssets.filter((f) => /\.appimage$/i.test(f.name))),
2 participants
小问题
x86_64被误判为x86.AppImage大小写问题不太顺眼
platformName之间增加空格title和desc