内存三巨头：Macron，Samsung，SK hynix
这一波涨价可能要持续 2-3年之久，第一是因为 AI 大火，RAM，GPU 需求暴涨， 第二内存厂商在经过 COVID-19 消费端需求暴涨产出了过剩的RAM芯片，导致 AI 这一个极度不稳的棋，所有厂商都不愿意扩产。
有人用并不存在的钱，购买了大量尚未生产的内存，准备安装在同样尚未生产的GPU上，再放进尚未建造的数据中心，由可能永远不会出现的基础设施供电，以满足实际上并不存在的需求，并获取从数学上讲不可能实现的利润。
就连苹果也下水来涨价了。这一轮链上的共识，大家都非常的统一了战线。
多数媒体已经不建议在 2026年 配新的个人计算机了，在这里，我也一样。
2027年内存仍在高位吗？会的。
但不会好景太长，用不了太久就会回到一个合理的水平。
Bun.js 以高性能为卖点，而 PM2 可以提供nodejs作为服务的解决方案，而且支持cluster模式，可以最大限度的利用现代多核CPU性能。
但是我更关心 Bun.js 性能是否强到我来自己注册服务 来替换 PM2。
Bun 是一个高性能的 JavaScript 运行时，旨在提供 Node.js 的功能，同时提供更快的启动速度和更小的内存占用。它支持 ES6 模块，TypeScript，以及原生的 WebAssembly。Bun 还内置了一个 HTTP 服务器，使得开发和部署 Web 应用程序变得更加简单。
█ TOTAL RESULTS
HTTP
http_req_duration..............: avg=1.61ms min=274.48µs med=1.2ms max=39.05ms p(90)=2.77ms p(95)=3.87ms
{ expected_response:true }...: avg=1.61ms min=274.48µs med=1.2ms max=39.05ms p(90)=2.77ms p(95)=3.87ms
http_req_failed................: 0.00% 0 out of 42199
http_reqs......................: 42199 233.748209/s
EXECUTION
iteration_duration.............: avg=1s min=1s med=1s max=1.04s p(90)=1s p(95)=1s
iterations.....................: 42199 233.748209/s
vus............................: 4 min=4 max=500
vus_max........................: 500 min=500 max=500
NETWORK
data_received..................: 6.2 MB 35 kB/s
data_sent......................: 3.0 MB 16 kB/s
running (3m00.5s), 000/500 VUs, 42199 complete and 0 interrupted iterations
default ✓ [======================================] 000/500 VUs 3m0s
█ TOTAL RESULTS
HTTP
http_req_duration..............: avg=1.62ms min=241.31µs med=1.2ms max=71.94ms p(90)=2.66ms p(95)=3.59ms
{ expected_response:true }...: avg=1.62ms min=241.31µs med=1.2ms max=71.94ms p(90)=2.66ms p(95)=3.59ms
http_req_failed................: 0.00% 0 out of 42196
http_reqs......................: 42196 233.695522/s
EXECUTION
iteration_duration.............: avg=1s min=1s med=1s max=1.07s p(90)=1s p(95)=1s
iterations.....................: 42196 233.695522/s
vus............................: 4 min=4 max=500
vus_max........................: 500 min=500 max=500
NETWORK
data_received..................: 6.2 MB 35 kB/s
data_sent......................: 3.0 MB 16 kB/s
running (3m00.6s), 000/500 VUs, 42196 complete and 0 interrupted iterations
default ✓ [======================================] 000/500 VUs 3m0s
█ TOTAL RESULTS
HTTP
http_req_duration..............: avg=1.5ms min=232.55µs med=1.19ms max=59.78ms p(90)=2.51ms p(95)=3.3ms
{ expected_response:true }...: avg=1.5ms min=232.55µs med=1.19ms max=59.78ms p(90)=2.51ms p(95)=3.3ms
http_req_failed................: 0.00% 0 out of 42205
http_reqs......................: 42205 233.79981/s
EXECUTION
iteration_duration.............: avg=1s min=1s med=1s max=1.06s p(90)=1s p(95)=1s
iterations.....................: 42205 233.79981/s
vus............................: 4 min=4 max=500
vus_max........................: 500 min=500 max=500
NETWORK
data_received..................: 6.2 MB 35 kB/s
data_sent......................: 3.0 MB 16 kB/s
running (3m00.5s), 000/500 VUs, 42205 complete and 0 interrupted iterations
default ✓ [======================================] 000/500 VUs 3m0s
PM2 是一个用于管理 Node.js 应用程序的进程管理器。它提供了自动重启、负载均衡、集群模式等功能，使得 Node.js 应用程序更加稳定和高效。PM2 还支持多种监控和日志记录功能，使得开发者可以更好地了解应用程序的运行状态。
█ TOTAL RESULTS
HTTP
http_req_duration..............: avg=25.6ms min=704.67µs med=2.79ms max=2.75s p(90)=41.28ms p(95)=85.25ms
{ expected_response:true }...: avg=25.6ms min=704.67µs med=2.79ms max=2.75s p(90)=41.28ms p(95)=85.25ms
http_req_failed................: 0.00% 0 out of 41171
http_reqs......................: 41171 227.889771/s
EXECUTION
iteration_duration.............: avg=1.02s min=1s med=1s max=3.77s p(90)=1.04s p(95)=1.09s
iterations.....................: 41171 227.889771/s
vus............................: 1 min=1 max=500
vus_max........................: 500 min=500 max=500
NETWORK
data_received..................: 11 MB 60 kB/s
data_sent......................: 2.9 MB 16 kB/s
running (3m00.7s), 000/500 VUs, 41171 complete and 0 interrupted iterations
default ✓ [======================================] 000/500 VUs 3m0s
█ TOTAL RESULTS
HTTP
http_req_duration..............: avg=16.23ms min=662.87µs med=2.47ms max=636.8ms p(90)=34.98ms p(95)=78.24ms
{ expected_response:true }...: avg=16.23ms min=662.87µs med=2.47ms max=636.8ms p(90)=34.98ms p(95)=78.24ms
http_req_failed................: 0.00% 0 out of 41540
http_reqs......................: 41540 230.651456/s
EXECUTION
iteration_duration.............: avg=1.01s min=1s med=1s max=1.63s p(90)=1.03s p(95)=1.08s
iterations.....................: 41540 230.651456/s
vus............................: 3 min=3 max=500
vus_max........................: 500 min=500 max=500
NETWORK
data_received..................: 11 MB 60 kB/s
data_sent......................: 2.9 MB 16 kB/s
running (3m00.1s), 000/500 VUs, 41540 complete and 0 interrupted iterations
default ✓ [======================================] 000/500 VUs 3m0s
import http from 'k6/http';
import { sleep } from 'k6';
export const options = {
// Key configurations for Stress in this section
stages: [
{ duration: '1m', target: 500 }, // traffic ramp-up from 1 to a higher 200 users over 10 minutes.
{ duration: '1m', target: 200 }, // stay at higher 200 users for 30 minutes
{ duration: '1m', target: 0 }, // ramp-down to 0 users
],
};
export default () => {
const urlRes = http.get('http://localhost:5000');
sleep(1);
// MORE STEPS
// Here you can have more steps or complex script
// Step1
// Step2
// etc.
};
Bun 的性能要远好于 PM2 Cluster（express）。其实 Bun 也不是运行在单线程下的，Bun会自动发起多个线程来处理请求。
而且 Bun 对于 Serverless 应用的兼容性非常好，可以很好的平替（Cloudflare worker）。
推荐尽可能的不使用该版本，这个版本更多的情况是用于测试，而且界面风格大有问题。在这个版本中首次引入了docker-compose，早期用户迁移使用的这个版本。
Apps的迁移截止到2025年6月1日（目前已过时）。
如果没有及时迁移到这个版本中，需要手动再重新配置所有的Apps。
这个版本相对稳定了非常多，能够完全达到一个生产力的水平，且界面上已经没有什么大问题。
虚拟化非常强力，增加了 containers（Linux 实例），VM 增加了 Hyper-V，TPM 的支持。
在 24 的旧版本中，若要升级到新版本，可能会有大问题。
对于存储系统应当多备份。数据无价。
每次升级不要跨大版本，例如：24.04 -> 24.10 -> 25.04
最近一年的升级对虚拟化有显著提升，容器化则更轻量和灵活，即使是高阶用户，维护起来也更轻松（请勿没苦硬吃）。
ref: https://stackoverflow.com/questions/67459316/enabling-chromium-to-sync-with-google-account
已过时，不可靠的解决办法。
Still working as of July 2025 (Chromium 138)
Closed. This question is not about programming or software development. It is not currently accepting answers.
Google 宣布，从 2021 年 3 月 15 日起， Chrome 浏览器的开源版本 Chromium 将限制私人 API 的可用性。
变通办法：
使用设置了 oauth2 ID 和密码的标志启动 Chromium，可以重新启用 Chromium 与 Google 账户的同步。
例如，在 Arch Linux 上，可以创建内容为 ~/.config/chromium-flags.conf 的文件：
--oauth2-client-id=77185425430.apps.googleusercontent.com
--oauth2-client-secret=OTJgUOQcT7lO7GsGZq2G4IlT
也可以命令中传递标志。这应该适用于任何操作系统。（macOS未能同步）
这种方式不能保证未来的可靠性：
It looks like this id and secret come from sourcecode :
一个支持多存储的文件列表/WebDAV程序，使用 Gin 和 Solidjs。
可以挂载 S3，WebDAV，SMB，Google Drive，OneDrive 等多种存储，同时提供 WebDAV，S3 的协议支持，具有一个良好的Web界面。
项目所有权变更：据报道，AList 原开发者 Xhofe 已确认项目被出售给一家名为“贵州不够科技”的公司，但交易过程缺乏透明度，未提前向社区发布正式公告。
文档与代码修改：新接手方对 AList 的中文文档进行了大幅修改，加入了非技术性内容（如 微信链接），并更改了官网和下载地址。此外，部分代码提交（如添加操作系统信息统计功能）未经充分审核即被合并，引发了供应链攻击的担忧。
社区管理变动：AList 的 Telegram 群管理团队，原管理人员退出或匿名，官方沟通渠道的可靠性受到质疑。
历史案例的警示：新接手公司疑似曾收购其他开源项目（如 Java 工具库 Hutool ），并有类似争议行为。这进一步加剧了用户对 AList 未来发展方向的担忧。
不再继续信任 AList，使用社区衍生版 OpenListTeam/OpenList.
apk 是Alpine软件包管理器. 它用于管理系统的软件包（软件和其他）。它是安装附加软件的主要方法，在 apk-tools 软件包中提供。
OpenWrt 从 24.10 之后就开始使用 apk 来作为 包管理器了。
OpenWrt recently switched to the "apk" package manager!
OPKG Command APK Equivalent Description
------------------------------------------------------------------
opkg install <pkg> apk add <pkg> Install a package
opkg remove <pkg> apk del <pkg> Remove a package
opkg upgrade apk upgrade Upgrade all packages
opkg files <pkg> apk info -L <pkg> List package contents
opkg list-installed apk info List installed packages
opkg update apk update Update package lists
opkg search <pkg> apk search <pkg> Search for packages
------------------------------------------------------------------
For more https://openwrt.org/docs/guide-user/additional-software/opkg-to-apk-cheatsheet
open wrt 从 24.10 之后就开始使用 apk 来作为 包管理器了。
这个改进非常好，如果你用过 Alpine，你会发现 这两个发行版越来越相似，他们都还有一个共性，就是非常轻量级，和节省资源。
apk 的 API 整体要更简洁，安装器相对 opkg 兼容性更强。比较关键的是，不用额外再记一套API了，我非常赞成 openwrt 对包管理器作出的改进。
Darwin是macOS和iOS操作环境的操作系统部分。苹果公司于2000年把Darwin发布给开放源代码社群。
PureDarwin 项目旨在让 Apple 的开源 Darwin OS 更加易用，截至 2024 年仍在积极维护中。虽然开发速度相对较慢，但该项目仍在通过社区贡献取得进展。
PureDarwin 专注于创建一个独立于 macOS 组件的可用可启动系统，完全依赖于 Darwin 和其他开源工具。
Berkeley Software Distribution
BSDs strive to be coherent systems
BSD 努力成为一致的系统
八个月前，Reddit上发起了这个讨论：https://www.reddit.com/r/BSD/comments/1bn4zjx/why_bsd/
常见的 BSD 发行版：
从现在的发展来看，BSD 的生态正在越来越紧缩，Apple 自己建立的 darwin-xnu 也于 2023年5月 进入归档状态。
PureDarwin 的维护进度实在太慢，想从 PureDarwin 启动做一个 "Apple Server"， 看起来没那么容易，且未必有那个价值。
更多的 BSD 系统更在意功能，例如 TrueNAS 的 ZFS，和 pfSense 的 路由和防火墙，或者 macOS，iOS 这样的商业闭源系统。
整体看下来 BSD 的应用方向可能更在于封闭和统一，和 Linux 已经是完全截然不同的两条路了。
Rust 看起来 非常小而美，在我看来 几个优点非常看好。
Rust: https://actix.rs/
Java: https://docs.spring.io/spring-framework/reference/web/webflux/new-framework.html
K6: https://k6.io/
Rust:
data_received..................: 5.2 MB 29 kB/s
data_sent......................: 2.8 MB 16 kB/s
http_req_blocked...............: avg=266.24ms min=0s med=0s max=32.02s p(90)=0s p(95)=0s
http_req_connecting............: avg=266.24ms min=0s med=0s max=32.02s p(90)=0s p(95)=0s
http_req_duration..............: avg=309.86µs min=0s med=0s max=4.52s p(90)=692.3µs p(95)=796.5µs
{ expected_response:true }...: avg=174.08µs min=0s med=0s max=1.71ms p(90)=692.3µs p(95)=796.36µs
http_req_failed................: 0.01% 4 out of 33318
http_req_receiving.............: avg=38.61µs min=0s med=0s max=1.48ms p(90)=40.22µs p(95)=508.7µs
http_req_sending...............: avg=4.33µs min=0s med=0s max=1.02ms p(90)=0s p(95)=0s
http_req_tls_handshaking.......: avg=0s min=0s med=0s max=0s p(90)=0s p(95)=0s
http_req_waiting...............: avg=266.91µs min=0s med=0s max=4.52s p(90)=586.6µs p(95)=719.6µs
http_reqs......................: 33318 184.522672/s
iteration_duration.............: avg=1.26s min=1s med=1s max=33.02s p(90)=1s p(95)=1s
iterations.....................: 33318 184.522672/s
vus............................: 3 min=3 max=499
vus_max........................: 500 min=500 max=500
running (3m00.6s), 000/500 VUs, 33318 complete and 0 interrupted iterations
default ✓ [======================================] 000/500 VUs 3m0s
Java:
data_received..................: 5.0 MB 28 kB/s
data_sent......................: 3.6 MB 20 kB/s
http_req_blocked...............: avg=12.31µs min=0s med=0s max=10.9ms p(90)=0s p(95)=0s
http_req_connecting............: avg=9.79µs min=0s med=0s max=2.13ms p(90)=0s p(95)=0s
http_req_duration..............: avg=528.32µs min=0s med=550.6µs max=158.21ms p(90)=1.1ms p(95)=1.33ms
{ expected_response:true }...: avg=528.32µs min=0s med=550.6µs max=158.21ms p(90)=1.1ms p(95)=1.33ms
http_req_failed................: 0.00% 0 out of 42266
http_req_receiving.............: avg=63.55µs min=0s med=0s max=1.49ms p(90)=208.9µs p(95)=526µs
http_req_sending...............: avg=5.71µs min=0s med=0s max=4.74ms p(90)=0s p(95)=0s
http_req_tls_handshaking.......: avg=0s min=0s med=0s max=0s p(90)=0s p(95)=0s
http_req_waiting...............: avg=459.05µs min=0s med=523.7µs max=158.21ms p(90)=1.01ms p(95)=1.22ms
http_reqs......................: 42266 234.328464/s
iteration_duration.............: avg=1s min=1s med=1s max=1.16s p(90)=1s p(95)=1s
iterations.....................: 42266 234.328464/s
vus............................: 2 min=2 max=499
vus_max........................: 500 min=500 max=500
running (3m00.4s), 000/500 VUs, 42266 complete and 0 interrupted iterations
default ✓ [======================================] 000/500 VUs 3m0s
Rust
data_received..................: 7.1 MB 117 kB/s
data_sent......................: 3.9 MB 64 kB/s
http_req_blocked...............: avg=36.9µs min=0s med=0s max=4ms p(90)=0s p(95)=0s
http_req_connecting............: avg=34.73µs min=0s med=0s max=4ms p(90)=0s p(95)=0s
http_req_duration..............: avg=374.98µs min=0s med=522.9µs max=14.25ms p(90)=624.6µs p(95)=733.4µs
{ expected_response:true }...: avg=374.98µs min=0s med=522.9µs max=14.25ms p(90)=624.6µs p(95)=733.4µs
http_req_failed................: 0.00% 0 out of 45690
http_req_receiving.............: avg=35.15µs min=0s med=0s max=1.99ms p(90)=16.4µs p(95)=508µs
http_req_sending...............: avg=4.35µs min=0s med=0s max=1.76ms p(90)=0s p(95)=0s
http_req_tls_handshaking.......: avg=0s min=0s med=0s max=0s p(90)=0s p(95)=0s
http_req_waiting...............: avg=335.46µs min=0s med=516.35µs max=14.25ms p(90)=602.7µs p(95)=688.81µs
http_reqs......................: 45690 749.430697/s
iteration_duration.............: avg=1s min=1s med=1s max=1.01s p(90)=1s p(95)=1s
iterations.....................: 45690 749.430697/s
vus............................: 60 min=24 max=1498
vus_max........................: 1500 min=1500 max=1500
running (1m01.0s), 0000/1500 VUs, 45690 complete and 0 interrupted iterations
default ✓ [======================================] 0000/1500 VUs 1m0s
Java:
data_received..................: 5.4 MB 89 kB/s
data_sent......................: 3.9 MB 64 kB/s
http_req_blocked...............: avg=35.32µs min=0s med=0s max=6.03ms p(90)=0s p(95)=0s
http_req_connecting............: avg=33.13µs min=0s med=0s max=6.03ms p(90)=0s p(95)=0s
http_req_duration..............: avg=393.34µs min=0s med=518.59µs max=175.24ms p(90)=779.4µs p(95)=1.05ms
{ expected_response:true }...: avg=393.34µs min=0s med=518.59µs max=175.24ms p(90)=779.4µs p(95)=1.05ms
http_req_failed................: 0.00% 0 out of 45691
http_req_receiving.............: avg=40.46µs min=0s med=0s max=3.75ms p(90)=29.1µs p(95)=508.49µs
http_req_sending...............: avg=3.83µs min=0s med=0s max=1.7ms p(90)=0s p(95)=0s
http_req_tls_handshaking.......: avg=0s min=0s med=0s max=0s p(90)=0s p(95)=0s
http_req_waiting...............: avg=349.04µs min=0s med=217.5µs max=174.24ms p(90)=676.1µs p(95)=1ms
http_reqs......................: 45691 749.01963/s
iteration_duration.............: avg=1s min=1s med=1s max=1.17s p(90)=1s p(95)=1s
iterations.....................: 45691 749.01963/s
vus............................: 68 min=24 max=1498
vus_max........................: 1500 min=1500 max=1500
整体来看， Java 这边在Spring这个大框架下 只慢了一丢丢，大多都输在延迟上，但是也是有两大神器提供的加持，Java 23 和 Reactive, 所以只能说是没输。
而 Rust 这边，则是以微小领先取得了胜利，但是并没有拉开太大的差距。且第一轮对决出现了 4 个 failed（可能是测试条件问题）。
所以选择哪个语言和框架，区别应该在于场景下，比如想要更小的体积和更快的启动速度，那么 Rust 是最优选。
但是如果想要生态支持和更多开发者的协作，可能还得是 Java。
现在 再使用 pip install 可能会 提示以下消息
error: externally-managed-environment
× This environment is externally managed
╰─>
The system-wide python installation should be maintained using the system
package manager (apk) only.
If the package in question is not packaged already (and hence installable via
"apk add py3-somepackage"), please consider installing it inside a virtual
environment, e.g.:
python3 -m venv /path/to/venv
. /path/to/venv/bin/activate
pip install mypackage
To exit the virtual environment, run:
deactivate
The virtual environment is not deleted, and can be re-entered by re-sourcing
the activate file.
To automatically manage virtual environments, consider using pipx (from the
pipx package).
note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.
你可能需要 将 pip install somepackage 替换为 apk add py3-somepackage (Alpine Linux).
其实这是一个好消息
@xixigo
本人今年 36 岁，本科毕业于一所很普通的院校（非 211 ），之前一直在一线城市从事软件开发方面的工作。刚开始用 MFC 写上位机，主要是跟硬件交互，后来用 qt 做了几款编辑器软件。在工作了 6 年之后，有感于桌面软件的技术面太窄，转行学 go 语言，成了一个 web 后端工程师。刚开始还有点热情，学了 docker 、k8s 、微服务，发现后端开发比做桌面软件更没技术含量，都是拿现有的框架，写写 api 。也接触了很多后端开发工程师，总的感觉就编码能力比桌面软件工程师差太多了。因为工作太无聊，于是在 github 上写了几个开源项目，目前 star 已超过 1k 。
在 2017 年由于区块链的爆发，刚开始只是买点币，玩一玩。慢慢的觉得这是一个很有意思的领域，也开始学习区块链方面的知识，包括各种共识算法，合约开发，不管他的未来怎样，至少它不像其他领域那版枯燥。在做足了准备之后，面试通过了一家公司的区块链开发岗位。进入公司以后，发现周围的同事全是中科院、华为、腾讯等过来的大牛，因为那时候区块链正是风口，这个行业不差钱。 当然没过多久熊市就来了，公司也很快撑不下去，欠薪倒闭，最后大家一起去了劳动仲裁。在劳动仲裁填表的时候，才发现很多技术水平很菜的同事，工资竟然比我高很多，当然也有一些技术很厉 害的工资比我低，才发现面试时候谈薪是多么重要。
在区块行业寒冬之后，我又回到了传统互联网行业。
去年的时候刚好又到了这个尴尬的年纪，在一线城市又买不起房，于是回到了二线城市生活。 其实在此之前，我已经有这方面的打算，两年前就在某二线城市买了房，就想着有机会在二线城市找份工作，然后回来生活。经常时不时登上招聘网站，看看有没有合适个工作，虽然也有一些，但是薪资都比较低。后来看到一份 rust 区块链开发的岗位，支持远程办公，于是花了一个月时间学习了 rust 语言，抱着试试的心态投了简历，最后竟然面试通过了。后来就顺理成章地离开了一线城市，回到某二线城市生活。这个二线城市并非老家，而是一个我很喜欢的沿海城市，人口很少，常年在中国宜居城市榜首位置，因为我毕业后的第一份工作在这里，后来就喜欢上了这个城市。
回到二线城市每天早上 9 点开始办公，因为很多同事在北美，所以一般都是上午远程会议，下午就自由安排时间，周末双休。只要开会的时候人在就可以了，其他的时间，你在干嘛没人知道。不过我还是很自律的，每天 9 点按时坐在电脑前，6 点钟关闭电脑。吃完晚饭，休息一两个小时，然后在小区里面跑步，我们小区超级大，跑一圈大概有 3 公里。有时候，家里有啥事，出去半天，晚上回来再加班写代码。有时候线上环境有问题的时候，也会半夜爬起来修 bug 。远程办公没有 996 ，靠的全是自觉。像这种紧急情况要改 bug 的时候，一般都要填加班单，然后可以调休。
最近也看到很多大厂裁员， 我也担心的是这份工作能持续多久。我经常关注网上是否有远程开发的岗位，看看他们的需求，远程岗位大部分在海外，对英语口语有一定要求。我 现在的同事虽然有些在海外，但都是润出去的华人，都是说中文。为了未来打算，我现在要把口语学好，（ ps 我英语 4 级都没过），最近发现抖音上有一些英语角，是个非常好的练习口语的地方。现在每天晚上都上去听他们瞎聊，偶尔上麦聊几句。
对于远程办公，父母都不知道我在干嘛，以为在搞什么非法的活动，也没法跟他们说解释！
对于薪资，跟我在一线城市的时候差距不大，月薪差不多，不过去年年终 4 个月，还是挺满意的
original: https://cn.v2ex.com/t/947355
@coolrice1
我是从上海封城开始开始远程办公的，和 op 不一样的是我不是找了远程办公的工作，是我们老板在上海解封之后把办公室退了，让员工都远程在家办公，我以前在昆山买的房子，现在就住自己的房子，偶尔老板需要我们线下见一下也方便过去，说说我自己这一年远程办公的感觉吧。 好处：