工具与资源github.com
LocalStack：功能完整的本地 AWS 云栈
LocalStack – A fully functional local AWS cloud stack
2017 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
LocalStack 是一个在本地模拟 AWS 云服务的开源项目，让开发者能在自己的机器上跑 S3、Lambda、SQS、DynamoDB 等服务的替代实现，从而离线开发和测试依赖 AWS 的应用，而不必每次部署到真实云端。项目最初挂在 Atlassian 的 GitHub 组织下，后来独立为 localstack/localstack。
为什么经久不衰：它直击云端开发最痛的环节——本地难以复现生产环境、每次测试都要花钱和等待，因此多年来一直是本地云开发与 CI 测试的常用工具。
HN 评论精选
本地模拟 AWS 能降低测试的成本和心理门槛，是开发者真正需要的。
用 AWS 做生产平台最大的『缺点』之一，就是很难让开发环境看起来像生产环境。必须部署才能测试既麻烦又每次都产生费用，这会带来某种压力，让人不愿意频繁地小步测试。不知道这个项目能否改变这一点——能本地跑 S3、Lambda、SQS 听起来非常有意思，我会持续关注。另外我还希望看到 CloudFront，它因为不透明而很难上手，配置改动要等 20 多分钟，很打击积极性。
timvdalen查看英文原文
Huh. One of the biggest 'drawbacks' of using AWS as a production platform is that making your development environment look like production is hard. Having to deploy to test is cumbersome and having a cost associated with each test can definitely introduce some sort of 'stress' and encourage people to not test incrementally. I wonder if this changes that. Having services like S3, Lambda and SQS available locally sounds super interesting. I will definitely keep an eye on this. One other thing I would like to see is CloudFront, which can be very hard to start with due to its opaqueness. Having to wait 20+ minutes between configuration changes is very demotivating.
实际大规模使用后问题不少：文档缺失、CloudFormation 不完整、API 不全，别指望它是万能方案。
最近用它尝试离线跑一个大型 serverless 应用做开发，勉强能用但体验只是还行，不算好。他们似乎把精力都花在为新的（付费）服务做 mock 上，而早期那些 mock 有大量问题值得先整合修好：文档几乎没有，得翻 GitHub issue 才能搞懂怎么用（比如 API Gateway 的调用）；CloudFormation 实现基本是坏的（不支持内置函数），除非你的栈很简单，否则只能用 Terraform 这类基于 API 的工具；API 也不完整，导致 Terraform 重新部署时取资源状态会失败，或者每次都触发某些资源重建（我们用到最冷门的也只是 SNS）；测试套件很单薄，见过好几次 CI 被弄挂；行为也不一致，设了环境变量却发现某个场景根本没实现；基本要做好自己提 PR 修的准备。这不是抱怨，我理解它是半开源的、有问题可以自己修，只是提醒那些以为它是银弹的人：你得走完这些坑。
bazza451查看英文原文
Been using it recently to try and run a large serverless app offline for dev purposes, it kind of works but the experience is ok...not great. They seem to be piling all their energy into creating mocks for new (paid) services when it might be worth consolidating as the original mocks have a lot of issues. - Documentation is non-existent, expect to trawl through github issues to work out how something works as it’s quite opaque (api gateway invocation) - CloudFormation implementation is completely broken (no intrinsic functions) so unless your stack is simple you’re pretty much required to use any AWS api based devops tools (e.g. Terraform) - API’s are not fully complete, means terraform either breaks on redeploy when it tries to get a resources status or at best case triggers redeploy of certain resources each time (the most exotic thing we’re using is SNS) - Test suite is...light, seen a few things go through their CI and break it - There’s a bit of non-consistent behavior - you’ll set an env var and find it’s not implemented for a certain case and be left scratching your head - Expect to have to make pull requests yourself to fix things This isn’t a winge, I understand it’s partially open source and you can just fix the issues yourself when they come up like we are doing. But just a heads up for who may naively look at it and think it’s a silver bullet...you’ll have to go through all these steps.
故障注入能力是亮点：真实环境里难以复现的错误场景，本地可以主动制造。
根据文档，它支持本地故障注入（可以指定返回『资源不可用／耗尽』），这使它在开发时『比真货还好用』。（不过我没用过，无法评价效果如何。）我通常倾向于在尽量接近真实的 live 环境上开发，因为测试环境常会漏掉关键东西；但错误路径的行为往往在测试和线上都难以验证——要调试 S3 报错或资源耗尽，你得真的让它发生。这个项目似乎正好能测这些情况，很妙。
beagle3查看英文原文
According to the docs, it has local fault injection (I.e. you can tell it to respond with “resources unavailable / exhausted”) which makes it “even better than the real thing” for development. (But have never used it so cannot comment about how well that works). I usually prefer to develop against as-live-setup-as-makes-sense, because test environments often miss something critical; however, it is often hard to verify (on both test and live systems) error condition behaviour - to debug response to S3 errors or resource exhaustion, you actually need them to happen. Looks like this project does provide for testing these conditions. Neat.
在 CI 中 mock DynamoDB/SQS/Kinesis/SNS 的实际体验良好，只有个别小坑。
我来补充一句：我最近两家雇主都用 LocalStack 在 CI 里『mock』AWS，一路顺利，mock 了 DynamoDB、SQS、Kinesis 和 SNS 都没问题。唯一一个坑是 FIFO 队列的命名方式，另外 SQS 相关的某个默认参数不被接受，除此之外很顺畅。
therein查看英文原文
I figured I would chime in. I've used LocalStack to "mock" AWS in CI for my two most-recent employers and worked without a hitch. Mocked DynamoDB, SQS, Kinesis and SNS without an issue. There was a single gotcha about the way that the FIFO queues needed to be named and it also didn't accept a default parameter for something relating SQS but other than that it was smooth sailing.
历次讨论
同类还值得读
直接在浏览器中启动 Linux 内核
Boot a linux kernel right inside your browser.
Fabrice Bellard 的 JSLinux 页面，用 JavaScript 在浏览器里启动一个 Linux 内核，并提供一个可交互的终端环境。
工具与资源上首页 5 次 · 2011–2025bellard.orgHacker News 未公开功能与行为清单（2018）
A List of Hacker News's Undocumented Features and Behaviors (2018)
数据科学家 Max Woolf 整理的 Hacker News 未公开功能与行为清单，涵盖投票机制、排名算法、账号惩罚等社区运作细节。
工具与资源上首页 5 次 · 2019–2025github.comMapSCII：在终端中用盲文和 ASCII 渲染地图
MapSCII – Braille and ASCII map renderer for the console
MapSCII 是一个在命令行终端里渲染地图的开源工具，用盲文字符和 ASCII 字符把地理数据画成可交互浏览的字符地图。
工具与资源上首页 5 次 · 2017–2025github.com顶尖大学的免费在线课程
Free Online Courses from Top Universities
Open Culture 整理的一份免费在线课程合集，汇集了全球顶尖大学（如 MIT、斯坦福、耶鲁等）向公众开放的网络课程资源，涵盖音频、视频等多种形式。
工具与资源上首页 5 次 · 2010–2022openculture.com淘气字符串：容易引发用户输入问题的字符串清单
Naughty Strings: A list of strings likely to cause issues as user-input data
一个 GitHub 仓库，收录了大量容易让程序出问题的用户输入字符串，如特殊字符、emoji、SQL 注入片段、系统命令等，供开发者用于测试输入处理逻辑。
工具与资源上首页 4 次 · 2015–2020github.com