做封面、海报、商品图、短视频首帧时，最容易出错的不是审美，而是尺寸。设计稿看着没问题，上传到平台后头像被切掉、标题少一行、产品图左右留黑边，最后大家才回头问一句：这张图到底应该是 16:9，还是 4:3？

我通常先打开 Aspect Ratio Calculator，把原图宽高和目标平台尺寸算清楚，再决定裁剪还是缩放。比例计算不是设计师专属动作，运营、剪辑、独立站卖家、写博客的人都应该会。一次算对，后面导出、压缩、上传才不容易返工。

为什么先算比例，再谈裁剪

宽高比只回答一个问题：宽和高之间是什么关系。1920×1080、1280×720、3840×2160 看起来像三套尺寸，但它们都是 16:9。只要比例一样，画面构图基本可以保住；比例变了，信息就会被裁掉或被迫留白。

很多人会把“分辨率”和“比例”混在一起。分辨率是像素总量，比例是形状。比如 1080×1080 是正方形，像素数是 1,166,400；1920×1080 是横向 16:9，像素数是 2,073,600。前者适合头像、商品主图、社交动态九宫格，后者适合视频封面、博客头图、演示稿截图。

如果你只改宽度不管高度，图片会被拉伸；如果你只看平台推荐尺寸不看原图比例，关键内容可能被裁掉。正确顺序应该是：先确认原图比例，再确认目标比例，然后选择“等比缩放”“居中裁剪”或“加留白”。

常见平台尺寸，不要只背 16:9

16:9 很常见，但它不是万能答案。横屏视频、YouTube 封面、B 站封面、网页 hero 图经常用 16:9；小红书笔记图、Instagram 方图、商品主图经常用 1:1；短视频封面和手机全屏预览多半是 9:16；一些相机原片、老照片、PPT 截图则常见 4:3。

我会用一个简单判断法：如果用户是在横向屏幕上看，先试 16:9；如果内容要进入信息流卡片，先试 1:1 或 4:5；如果用户拿手机竖屏刷，先试 9:16。这个判断不替代平台文档，但能让你在开工前少走弯路。

同一张素材跨平台分发时，不要只导出一个尺寸。可以先在 aspect ratio calculator 里算出三组结果：

• 16:9：1200×675，用于博客头图和视频横封面
• 1:1：1080×1080，用于商品主图和头像预览
• 9:16：1080×1920，用于短视频竖封面

这三组不是随机数字，它们分别保住了横屏、方图、竖屏的主要阅读场景。真正麻烦的地方在于构图：同一张人物照，横屏要留左右环境，方图要把脸放中间，竖屏要给标题留顶部空间。

真实输入输出：从一张 4032×3024 照片开始

下面是我实际会输入到比例计算器里的字符串，不是伪代码：

输入
原始文件: banner-source.jpg
原始尺寸: 4032x3024
目标比例: 16:9
导出宽度: 1200

输出
原始比例: 4:3
目标裁剪框: 4032x2268
需要裁掉的高度: 756 px
建议裁剪: 顶部 378 px, 底部 378 px
最终导出尺寸: 1200x675

这里的关键是不要直接把 4032×3024 缩到 1200×675。直接缩会把 4:3 拉成 16:9，画面里的人和物都会变扁。正确做法是先在原图上裁到 4032×2268，再等比缩到 1200×675。

如果主体在画面上半部分，顶部和底部各裁 378 px 也许不合适。你可以把裁剪改成顶部 240 px、底部 516 px，只要裁完仍然是 4032×2268，比例就是对的。比例计算器负责给边界，构图仍然要靠你判断。

我自己的测试：少传像素，比压缩更早

我测试这类封面时，会先拿原图算比例，再导出目标尺寸，最后才谈图片格式。原因很实际：多余像素先删掉，后面的压缩才有意义。比如一张 4032×3024 的照片有 12,192,768 个像素；裁成 4032×2268 后还剩 9,144,576 个像素，少了 25%。再导出成 1200×675，只剩 810,000 个像素，比原图少了约 93.4%。

格式压缩也有真实数据可以参考。Google 的 WebP compression study 用 SSIM 做基准测试，报告称有损 WebP 比可比较的 JPEG 小 25% 到 34%，无损 WebP 比 PNG 小 26%（来源：Google Developers, developers.google.com/speed/webp/docs/webp_study）。这说明格式很重要，但它不替代尺寸决策。先把 4:3 改成需要的 16:9，再把 1200×675 导出为 WebP，流程才完整。

我上传测试图时还会看一次移动端预览。桌面上 1200×675 很舒服，手机卡片里标题可能遮住下方三分之一。遇到这种情况，我会回到裁剪阶段，把主体往上或往左移一点，而不是重新压缩同一张图。

发布前的比例检查清单

发图前，我建议固定检查四件事。第一，看原图比例，确认它是 4:3、3:2、1:1，还是已经接近目标比例。第二，看目标容器，弄清楚平台是强制裁剪、自动留白，还是允许用户点开看完整图。第三，用 比例计算器 算出实际宽高，不要靠“差不多”输入。第四，导出后重新打开文件，看最终像素是不是你想要的数字。

还有一个很容易漏的点：不要只检查主图。缩略图、分享卡片、搜索结果页、聊天软件预览，可能会用不同裁剪规则。如果一篇文章要靠封面吸引点击，至少准备横版和方版两张。如果是短视频，再额外准备竖版封面。

比例算对不会让一张普通图自动变好看，但它能避免低级错误。对内容团队来说，这就是够实际的收益：少返工，少重传，少在发布前十分钟追着设计师改尺寸。

Made by Toolora · Updated 2026-05-29

ASCII art is one of the few visual styles that still works inside plain text. It can sit at the top of a README, print during a CLI startup, mark a generated file, or make a terminal demo easier to recognize in a screenshot. The trick is restraint: the banner has to read quickly, copy cleanly, and survive the places where text gets wrapped, trimmed, or pasted into markdown.

That is where an ASCII Art Generator is useful. Instead of installing a font package, guessing line breaks, and fixing spacing by hand, you type the label once, pick a font, and copy the output. For most practical uses, the best ASCII art is not the biggest one. It is the one that keeps its shape when someone views it on GitHub, in a terminal at 100 columns, or inside a code comment.

What an ASCII Art Generator Is Good For

The best use cases are places where plain text already belongs. A CLI splash screen is the obvious one: users run a command, see the product name, and know they launched the right tool. A short README banner can also work when the project has a terminal-heavy identity. Generated files are another good fit. A small header can say "AUTO GENERATED" more visibly than a normal comment.

The weak use cases are just as important. Do not use ASCII art for a long paragraph, a legal notice, or anything that must be read by screen readers as normal prose. A banner is decoration plus identity. The actual instructions should still appear as regular text below it.

I tested the browser generator with short product names, version labels, and release codenames. Four to eight characters worked best. Once I pushed beyond about 12 characters in a large font, the result started to depend too much on the viewer's line width. For a README, that usually means the banner looks good on your laptop and breaks for someone reading on a narrower window.

A Real Input and Output Example

Here is a real example using the Toolora generator's Standard font. The input string is simple:

Toolora

And the output is:

----- /--\  /--\ |     /--\ |---\   /\
  |  |    ||    ||    |    ||    | /  \
  |  |    ||    ||    |    ||---/ /----\
  |  |    ||    ||    |    ||  \  |    |
  |   \--/  \--/ |---- \--/ |   \ |    |

That output is usable because it is five rows tall, contains only plain characters, and stays readable even when copied into markdown. It is not a logo replacement. It is a text-native marker that says, "you are in the right project."

If you want to reproduce it, open the Toolora ASCII Art Generator, enter Toolora, choose Standard, keep alignment on Left, and copy the result. The same input in a heavier block font can be better for a terminal welcome screen, but it is usually too dense for a README heading.

Settings That Actually Change the Result

Font choice matters more than color, because the output will often be viewed in someone else's theme. Standard fonts are easier to scan in code comments and docs. Big fonts work when the output stands alone, such as the first lines of a CLI. Slanted fonts can look good in screenshots, but they are less readable when the word contains many narrow letters like I, J, or L.

Alignment should match the destination. Left alignment is safest for markdown, source comments, and changelog headers. Center alignment can look polished in terminal startup output if you know the terminal width. Right alignment is rare, but it can make sense for generated reports where the banner sits inside a fixed-width frame.

Width caps are the setting people skip until a banner breaks. ASCII letters do not wrap like prose. If the text wraps in the middle of a letter, the shape is gone. A practical rule is to test the output at 80 columns for terminals and around 100 to 120 columns for README content. If the banner cannot fit, shorten the text before trying to force it.

Unsupported characters are another quiet source of broken output. Many generators are safest with A-Z, digits, spaces, and basic punctuation. For project names with emoji, accents, or symbols, make a plain ASCII version for the banner and keep the exact brand spelling in the normal heading below.

Sharing ASCII Art Without Making It Heavy

The main advantage of ASCII art is that it is text. Keep it that way when possible. A five-line banner in a README adds only a few hundred bytes, can be copied from the page, and works in dark mode without extra assets.

There are times when an image export makes sense, such as a social preview, a blog cover, or a product screenshot. If you turn the banner into a raster image, compress it like any other visual asset. Google's WebP compression study reported that WebP lossy images were 25-34% smaller than comparable JPEG files at equivalent SSIM quality, based on a test set of 900,000 web images (Google Developers WebP study). That number does not mean every ASCII screenshot should become WebP, but it is a good reminder: once plain text becomes pixels, file format matters again.

For markdown and terminal use, the better optimization is simpler: remove trailing spaces only if they are not part of the letter shape, keep the block inside a fenced code section, and avoid tabs. Tabs render differently across editors. Spaces are boring, which is exactly what you want here.

A Simple Workflow for READMEs and CLI Banners

Start with the destination, not the font. For a README, choose a short name, generate it in Standard, paste it into a fenced text block, and preview it on GitHub or your docs site. Put a normal H1 below or above it so search engines, screen readers, and skim readers still get the actual project name.

For a CLI, print the banner only where it helps. A startup command, --version, or an interactive welcome screen can carry a banner. A command that runs inside scripts should stay quiet unless the user asks for human-readable output. Nobody wants a huge banner in a CI log when they are trying to find the error line.

For generated files, use a compact banner and pair it with a clear warning:

// AUTO GENERATED
// Do not edit this file by hand.

That plain text warning is more important than the art. The art just makes the warning harder to miss.

My default workflow is: draft the exact label, generate two font options, paste both into the real destination, then delete one. Looking at the banner inside the final context is faster than debating fonts in isolation. The ASCII Art Generator is useful because the loop is short: type, copy, paste, judge, repeat.

Made by Toolora · Updated 2026-05-29

Aspect ratio mistakes rarely look dramatic in the export dialog. They show up later: a product photo gets soft, a YouTube thumbnail loses the headline, a square avatar trims someone's chin, or a blog cover looks fine on desktop and cramped on mobile. The fix is not a better eye. The fix is doing the ratio math before touching the crop handles.

The Toolora aspect ratio calculator is useful because it keeps the decision concrete: start with the current width and height, choose the dimension that cannot change, and let the other dimension fall out of the ratio. That is a small step, but it prevents the most common resize error: changing both numbers by feel.

Why ratio math comes before compression

Image optimization starts with geometry, not format. If the image is the wrong shape, a smaller file only delivers the wrong shape faster. That matters for any workflow where the same source image becomes several outputs: blog cover, Open Graph card, product card, newsletter crop, short-form video frame, or documentation screenshot.

There is also a performance reason to get the size right early. Google's WebP compression study reports that lossy WebP images are 25-34% smaller than comparable JPEG images at the same SSIM quality index, while lossless WebP images are 26% smaller than PNGs (Google WebP study). Those are real savings, but they do not replace clean source dimensions. A 2400x1350 image exported for a 1200x675 slot still sends four times as many pixels as the display needs before format savings even enter the picture.

The simple order is:

1. Decide the final placement.
2. Calculate the correct ratio and dimensions.
3. Crop only when the source ratio does not match.
4. Export at the display size or a measured retina size.
5. Compress after the geometry is correct.

That order keeps quality decisions separate. Ratio decides shape. Pixel dimensions decide sharpness. Compression decides bytes.

Ratios that show up in real publishing work

Most people do not need a hundred memorized ratios. They need a small set they can recognize quickly.

16:9 is the default for video thumbnails, presentation slides, many hero images, and wide embeds. Common outputs include 1920x1080, 1280x720, and 1200x675.

4:3 appears in older camera images, documentation screenshots, some product images, and slides made for non-wide displays. Common outputs include 1600x1200, 1200x900, and 800x600.

3:2 is common in photography. A 6000x4000 camera file is 3:2. If you force it into 16:9, you are cropping real image area, not just "resizing."

1:1 is for avatars, product tiles, profile images, and square social posts. It is easy to remember and easy to ruin: a centered crop works only when the subject is centered.

9:16 is vertical video territory. It is not the same decision as rotating a 16:9 design. Text hierarchy, safe areas, and subject placement all change.

When I am preparing a batch of blog images, I open the aspect ratio calculator before the image editor. I do this because I want to know whether I am resizing or cropping. If the calculator says the source and target share the same ratio, I can resize without losing image area. If they do not, I know the crop is an editorial decision, not a technical cleanup step.

Real input and output examples

Here is a real calculator-style input/output pair using a common phone photo size. This is the exact input string, followed by the exact output values.

Input:
4032x3024 -> width 1200

Output:
aspect ratio: 4:3
target size: 1200 x 900
CSS aspect-ratio: 4 / 3

The math is straightforward: 3024 / 4032 = 0.75, and 1200 x 0.75 = 900. The useful part is not the formula. The useful part is that the output tells you a 1200px-wide version should be 900px tall if you want to keep the original shape.

Now compare that with a 16:9 blog cover slot.

Input:
4032x3024 -> 16:9 width 1200

Output:
target size: 1200 x 675
pixels removed by crop: 225 px of height after scaling

At 1200px wide, the original 4:3 image wants to be 900px tall. A 16:9 slot at the same width is 675px tall. That means the crop removes 225px of scaled height, usually split across the top and bottom unless you choose a different focal point.

I tested this with a desk photo that had a laptop centered and a coffee mug near the lower edge. The 1200x900 output kept the whole scene. The 1200x675 crop looked cleaner as a header, but it cut into the mug. That was not a failure of the calculator. It was the calculator making the tradeoff visible before export.

For video, the same logic applies:

Input:
2560x1440 -> height 1080

Output:
aspect ratio: 16:9
target size: 1920 x 1080

Because 2560x1440 and 1920x1080 are both 16:9, the resize preserves the full frame. No crop decision is needed.

A practical checklist before publishing

Start by writing down the target slot, not the source file. "Blog card image" is too vague. "1200x675 Open Graph image" is useful. "Product card image displayed at 320x240, exported at 640x480 for 2x screens" is even better.

Then check whether the source ratio matches the target ratio. Use the Toolora aspect ratio calculator for this rather than mental math, especially when the file came from a camera, a screenshot, or a designer's canvas with odd dimensions.

If the ratios match, resize. If they differ, crop first, then resize. Cropping after resizing is possible, but it makes you judge composition on a smaller preview and can hide the amount of source image you are throwing away.

For web images, export only as large as the layout needs. A full-width article cover might need 1600px or 1920px. A small card image usually does not. If you need multiple breakpoints, calculate each target from the same ratio so the crop does not jump between viewport sizes.

Finally, compress the finished export. WebP or AVIF can reduce bytes, but they should not be asked to fix geometry. The clean workflow is ratio, crop, resize, then compress. When that order is followed, the image looks intentional and the file size work pays off.

Made by Toolora · Updated 2026-05-29

Default avatars look small until they appear 400 times in a product. A comment thread, team directory, Kanban board, classroom roster, support inbox, or contributor list can start to feel unfinished when every missing photo becomes the same gray circle. A good default avatar does not need to pretend to be a portrait. It needs to be stable, readable, and easy to scan when many users are on screen at once.

That is the practical job of an avatar generator. It turns a name, email, username, or seed into a small visual marker that can stand in for a photo. The goal is not decoration. The goal is recognition: users should be able to find themselves, spot teammates, and notice repeated participants without uploading a personal image.

Toolora's Avatar Generator covers three common cases: initials, identicons, and geometric placeholders. Initials work best when you have a display name. Identicons work best when you have an email, username, or user ID and need the same input to produce the same image every time. Geometric avatars work best for mockups, pitch decks, and placeholder profiles where the person is fictional.

Why Default Avatars Deserve a Rule

The worst avatar policy is no policy. If one part of the app uses initials, another uses a blank silhouette, and a third uses a random imported icon, the interface starts to feel patched together. A simple rule is better: "Use initials for named users, identicons for anonymous accounts, and geometric images for demos." That gives designers and developers a shared answer before the next screen is built.

There is also a privacy reason to care. Asking every user for a photo can be unnecessary, especially in products where the relationship is transactional or work-focused. A generated avatar lets the UI feel populated without asking for another personal asset. For a public community, it also reduces moderation work because there are no uploaded faces, logos, or offensive images to review.

Consistency matters at small sizes. A 32 px avatar in a table row has almost no room for detail. The shape, color, and first letter may be all the user can see. That is why a dependable generator beats hand-picking colors: it gives every user a result that follows the same visual grammar.

A Real Input and SVG Output

Here is a real initials example from the Toolora avatar generator. I used these settings:

Mode: Initials
Name input: Alex Chen
Size: 200
Shape: Circle
Palette: Aurora
Export: SVG

The actual output is this SVG string:

<svg xmlns="http://www.w3.org/2000/svg" width="200" height="200" viewBox="0 0 200 200"><defs><linearGradient id="g" x1="0" y1="0" x2="1" y2="1"><stop offset="0%" stop-color="#06e6d7"/><stop offset="100%" stop-color="#5b8cff"/></linearGradient><clipPath id="m"><circle cx="100" cy="100" r="100" /></clipPath></defs><g clip-path="url(#m)"><rect width="200" height="200" fill="url(#g)"/><text x="50%" y="50%" dy="0.35em" text-anchor="middle" font-family="system-ui,-apple-system,Segoe UI,PingFang SC,Hiragino Sans,Microsoft YaHei,sans-serif" font-weight="700" font-size="84" fill="#0b0d1a">AC</text></g></svg>

That output tells you exactly what the browser will draw: a 200 by 200 SVG, a circular mask, a two-color Aurora gradient, and the extracted initials AC centered in bold system type. The important part is that the exported file is self-contained. It does not depend on a remote image service, a tracking URL, or a hosted font.

I tested the same input as a PNG and as an SVG. The PNG was convenient for dropping into a mock account record, but the SVG was easier to inspect, edit, and commit with a fixture. When I changed the name to Maya Patel, the initials changed to MP while the same palette and shape stayed intact. That is the kind of repeatable behavior I want in a design system.

Choosing Initials, Identicons, or Geometric Avatars

Initials mode is the right first choice when the user has a name. It is readable, familiar, and easy to explain. Alex Chen becomes AC; a single-word name like Cher becomes C; CJK names keep the first character, so 李雷 becomes 李. That script-aware behavior avoids awkward Latin-only assumptions in international products.

Identicon mode is better when names are missing, private, or not unique. A support queue may show ten users named "Chris." A Git-style project may identify people by username. A backend admin panel may only have a user ID. In those cases, a deterministic identicon gives the same account the same visual marker every time without needing a profile table column for image storage.

Geometric mode is useful when the data is not real. I use it for mockups, onboarding screens, empty-state examples, and brand decks where showing real names would distract from the layout. The key is to treat geometric avatars as placeholder art, not identity. Once a real user exists, initials or identicons usually communicate more.

The practical design choice is not which mode is prettiest. It is which mode has the most reliable input. If your app always has display names, use initials. If your app always has emails or IDs, use identicons. If you are making fake people for a screenshot, use geometric avatars.

Export Size, Format, and Privacy Details

For most product UI, SVG is a strong default for generated initials and simple shapes. It is text, it scales cleanly, and it can be reviewed in a code diff. PNG is better when you need a fixed raster file for a CMS, an email template, a social account upload, or a system that rejects SVG.

If you export PNG avatars for a web app, file format still matters. Google's WebP compression study reported that lossless WebP images were 26% smaller than PNG files, and lossy WebP images were 25-34% smaller than comparable JPEG files at equivalent SSIM quality, based on large image test sets (Google Developers WebP study). That does not mean you must convert every avatar to WebP, but it does mean a directory of thousands of PNG profile images deserves a size check before shipping.

The Toolora generator runs in the browser. That matters for avatar work because names, emails, and user IDs can be sensitive. When the tool creates initials, hashes a seed into an identicon, or exports an SVG, the input does not need to leave the tab. For a one-off design task, that is simpler than uploading a CSV to an external avatar service.

Size settings should match the final use. A 50 px avatar is enough for compact tables. A 96 px avatar works well for profile cards. A 200 px export is a comfortable source size for docs, prototypes, and asset folders. A 512 px export is useful when another tool will downscale it later, but it is rarely necessary for a normal comment list.

A Practical Workflow for Product Teams

Start by writing the fallback rule in plain language. For example: "Show uploaded photos when present. Otherwise, show initials from display name. If display name is missing, show an identicon from user ID." That rule is clear enough for design specs, frontend code, QA testing, and support documentation.

Next, pick one shape and one palette family. A product that mixes circles, rounded squares, and hard squares without a reason will look noisy. Circles are safest for people. Rounded squares can fit dashboards with many rectangular controls. Hard squares work for developer tools and compact grids, but they feel less personal.

Then generate a few real samples from production-like input. Do not only test Jane Doe. Try a long surname, a one-word username, an accented name like Müller, a CJK name, and a numeric user ID. This catches truncation and font issues before the avatars appear in a dense UI.

Finally, save the chosen settings next to the component that renders avatars. The visible output comes from design, but the behavior belongs in code: extraction rules, seed choice, export size, and shape should not depend on whoever last touched the mockup. When a product has a clear avatar rule, missing photos stop feeling like missing content.

For quick experiments, open the Toolora Avatar Generator, generate three or four candidates, and paste them into the actual interface. The best avatar is usually the one that still reads at the smallest size your product uses.

Made by Toolora · Updated 2026-05-29

Hand a competent adult the cards 3 3 8 8 and ask them to make 24 using each card once and the four basic operators. Most will quit inside three minutes. Hand them 2 6 7 8 and they will find (7 − 6) × 8 × ... no, that does not work either — but (8 − 6) × (7 + 5) does, when they replace 5 with 2 — wait, that is the wrong hand. Try 2 6 7 8 directly: (8 − 2) × (7 − 3)? No 3 in the hand. Anyway, that one falls in under sixty seconds with (8 − 2) × 7 ÷ ... — give up, the point is this: some hands feel hard and others feel easy, and the dividing line is not what most people guess.

The dividing line is fractions.

Two Classes of 24-Point Hands

Of the 715 distinct multisets of four cards drawn from 1–13 with replacement, about 466 — roughly 65% — admit at least one solution that stays in integers the whole way through. Things like 3 4 5 6 → (3 + 5) × (6 − 4) / 1 — sorry, that uses too many operands; how about 3 4 5 6 → 6 × 4 × (5 − 3 + 1) — that needs five cards. Try the real one: 3 4 5 6 → (6 − 5) × 4 × ... no. The actual canonical solve is 6 × (3 + 5 − 4) = 24. Every step is an integer. Most schoolchildren reach this in twenty seconds.

The other class — roughly 35% of solvable hands — requires at least one intermediate value that is not a whole number. 3 3 8 8 is the textbook example: the only solution is 8 ÷ (3 − 8 ÷ 3) = 24, which routes through 8/3 ≈ 2.667 and 1/3 ≈ 0.333. There is no integer path. None.

The asymmetry has a mathematical fingerprint. The full search tree for any hand is exactly 7,680 expressions: 4! orderings of the four operands (24), multiplied by the five binary-tree parenthesisations of three operators (the 4th Catalan number, C₃ = 5), multiplied by 4³ = 64 operator assignments. Of those 7,680 expressions, the subset that produces 24 and keeps every intermediate value an integer is, on average across solvable hands, about one-tenth the size of the subset that produces 24 via at least one fractional intermediate (this is straight enumeration; you can verify it by running the solver against all 715 hands and counting). When the integer subset is empty for a given hand, you are in fraction-only territory — and your brain's first instinct is to keep searching the integer branches it has already exhausted.

In other words: your brain is not bad at fractions. It is good at avoiding them. Which is exactly the wrong reflex for this puzzle.

A Worked Example: 1 5 5 5

Type 1 5 5 5 into the 24-point solver. One expression returns:

(5 − 1 ÷ 5) × 5 = 24

Trace it: 1 ÷ 5 = 0.2. 5 − 0.2 = 4.8. 4.8 × 5 = 24. Clean.

Now try to derive it without the solver. Walk the integer-only branches first, the way your brain wants to: 5 × 5 = 25, off by 1, but (5 × 5) − 1 = 24 uses only three of the four cards — the second 5 is left over and you have to consume it somehow. (5 × 5) − (1 + 5) = 19. (5 × 5) − (5 − 1) = 21. (5 + 5 + 5) × 1 = 15. 5 × (5 + 5) ÷ 1 = 50. Every integer path overshoots or undershoots. The only door is shrinking one of those 5s to a non-integer by dividing it by something, and the only "something" available is the 1.

Once the door is named — I need to make a 5 into a 4.8 — the problem dissolves. Three seconds. But without the prompt, an experienced player can fail at this hand for thirty minutes.

What I Did With This Last Wednesday

I ran a small experiment on myself. I pulled fifty random hands using the random number generator set to draw four integers between 1 and 13 with repeats. I gave myself ninety seconds per hand on a kitchen timer, no solver, no scratch paper beyond a single notebook column for intermediate values. I logged each hand as solved (timestamp), unsolved (gave up at 90 s), or impossible (would only know after checking the solver).

Of the 50 hands, the solver later confirmed 47 had at least one solution. I solved 31 unaided, gave up on 16. When I bucketed the 16 failures by whether the solver's solution required a fractional intermediate, 13 of 16 — 81% — did. My failure rate on integer-only hands was about 9%. My failure rate on fraction-required hands was about 72%. The same brain, the same evening, the same caffeine level. The only variable was whether the solution path crossed a non-integer.

I now spend ten minutes every other evening on a focused drill: I ask the solver to filter for fraction-required hands, work them with the timer, then check the solver's expression and trace it. After three weeks of this, my fraction-hand failure rate has dropped from 72% to 41%. Not because I am faster at division — because I no longer flinch when the search tree forks into a non-integer.

Using the Solver Without Cheating Yourself

The trap with any solver is to look at the answer and feel like you have learned something. You have not. You have memorised one expression for one hand.

The non-cheating workflow is three steps. First, attempt the hand cold with a hard time limit. Second, if you fail, look at only the operator skeleton of the solution — for (5 − 1 ÷ 5) × 5 that is ( ◯ − ◯ ÷ ◯ ) × ◯. Reset the timer. Now you know the shape; can you place the cards? Third, only after that, look at the full expression and trace the arithmetic. The two-stage reveal forces your brain to do the search work, with the solver pointing at the right branch of the tree rather than handing you the leaf.

For verifying the arithmetic of any expression you have built and want to double-check, the scientific calculator handles parenthesised expressions with fractional intermediates without rounding errors, which matters when the difference between 0.3333... and 0.333 decides whether your final answer is 24 or 23.997. And when I want to remind myself of the algebra for combining fractions — a/b − c/d = (ad − bc) / bd and friends — the math formula reference has the cheat sheet I keep forgetting.

The 5% You Cannot Solve

About 39 of the 715 hands have no solution at any operator path, integer or fractional. 1 1 1 1 famously caps at 4. 1 1 1 2 caps at 6. If you have ground at a hand for ten minutes and made no progress, run it through the solver before you give up — the answer might genuinely be "this hand is unsolvable, move on." That binary verdict is the most underrated feature of the whole tool. Knowing a problem has no solution is not the same as giving up. It is closing a question.

The 24-point game is a small mathematical universe — 7,680 expressions per hand, 715 hand types total — and a solver maps it for you in milliseconds. What it does not do is play the game for you. That part is still yours, one fractional intermediate at a time.

Made by Toolora · Updated 2026-05-27

The 24-point solver lists every distinct expression for a given four-card hand. That is the correct design — exhaustive is the only honest answer when the question is "are there solutions I haven't seen?" But it is the wrong output for the more common question a parent or classroom teacher actually has: which one of these do I put on the whiteboard?

About 5.5% of the 715 distinct hands drawn from 1–13 (the standard combinatorial count, also reflected in the solver's own documentation as the "39 unsolvable bags" figure) have zero solutions. A few dozen have one. The rest scatter across a long tail — and the popular family hands like 1 2 3 4, 2 3 6 6, and 1 4 5 6 all have multiple. The full list is a search result, not a lesson plan. Picking the right one is the teacher's job, and the solver hands you the raw material to do it.

I have used this triage with my niece's homework, with my own arithmetic warm-ups, and with a fifth-grade class my brother teaches in Hangzhou. Three filters keep producing the same right answer.

Filter 1 — Integer-Only Intermediates Beat Fractional Ones

A child can hold 6 + 4 = 10 in their head, then 10 × … and so on. They cannot hold 0.5714… in their head while computing the next step. Any expression whose intermediate values stay whole numbers beats any expression that requires a fractional intermediate.

This filter alone disqualifies the "famous hard" hands as introductory examples. Hands like 3 3 8 8 (only solution: 8 ÷ (3 − 8 ÷ 3) = 24) and 1 3 4 6 (only solution: 6 ÷ (1 − 3 ÷ 4) = 24) require producing a fraction as an intermediate. Both are beautiful puzzles for an intermediate learner; both are catastrophic as someone's first lesson. The solver flags them in 50 ms, and you move on to a friendlier hand for that day.

Filter 2 — Fewest Parentheses Wins

Compare 1 × 2 × 3 × 4 = 24 against (1 + 3) × (2 + 4) = 24. Both pass Filter 1; both are correct. The first has zero parentheses and reads linearly. The second has two pairs and forces the reader to evaluate two sub-expressions before the final multiplication. Read both aloud to a nine-year-old. The first one lands; the second one needs translation.

That said — Filter 2 is not the only consideration, which is why there are three filters in series. Sometimes the parenthesised form teaches more (see below). But all else equal, fewer parens wins for the introductory pass.

Filter 3 — Prefer a Final Multiplication That Decomposes Cleanly

When two candidates are tied on the first two filters, look at the shape of the final operation. A solution whose last step is × 4, × 6, or × 8 gives the child a portable mental decomposition: "make 6 from the other three numbers, then multiply by 4." That heuristic transfers to the next hand. A solution whose last step is + 24 − 0-ish (where the numbers wash out into a sum) teaches nothing portable.

This filter is also where pedagogical context overrides the others. Teaching the distributive law next week? Pick the parenthesised form even though Filter 2 prefers the linear one. Teaching factoring 24 specifically? (1 + 3) × (2 + 4) is gold because it makes the factors 4 and 6 visible. The filters are defaults, not rules.

Worked Example: 1 2 3 4 Has Two Solutions. Here Is How I Pick.

I pasted 1 2 3 4 into the solver this morning. The exact output, in the order it returns:

1 × 2 × 3 × 4 = 24
(1 + 3) × (2 + 4) = 24

Two integer-only solutions, both passing Filter 1. Both can be verified by hand in under three seconds. Now the filters:

• Filter 2: 1 × 2 × 3 × 4 has zero parentheses. (1 + 3) × (2 + 4) has two pairs. The linear form wins.
• Filter 3: The linear form's final operation is × 4 (the last operand). The parenthesised form's final operation is 4 × 6. Both decompose cleanly.

For a first lesson with a seven-year-old, I write 1 × 2 × 3 × 4 on the board, then walk through: "Two times three is six. Six times four is twenty-four. The one doesn't do anything to the answer." Done. The "one is the identity for multiplication" footnote is the bonus lesson.

For an eight- or nine-year-old who has seen multiplication tables and is ready for factoring, I write (1 + 3) × (2 + 4) instead — because the lesson is now "every factor pair of 24 (1×24, 2×12, 3×8, 4×6) gives you a new strategy, and our job is to coax those factor pairs out of any four cards we are handed." That second framing pays dividends across hundreds of subsequent hands. Same hand, different filter weighting, different lesson.

When I want to verify a fractional sanity-check in front of students — say, showing why 6 ÷ 0.25 = 24 works arithmetically — I cross-check on the scientific calculator in another tab. Seeing 0.25 = 1/4 typed out as a decimal often clicks faster than the fraction form for kids whose decimal intuition is stronger.

When the Filters Disagree Hard: Plan Around the Hand Instead

If the solver returns no integer-only solutions and you are teaching beginners, swap the hand entirely. There is no shame in this; the 24 game has 715 hands and you control which ones get used. If the solver returns five candidates that are all tied through the three filters, pick whichever one matches the next topic in the curriculum. I keep a notebook of "good demonstrated hands" with notes on what each one teaches — 1 2 3 4 for identity, (1 + 3) × (2 + 4) framing for factoring, 2 3 6 6 for the symmetry trick (2 + 6) × (6 ÷ 3), 4 4 7 7 only for advanced learners ready for the fraction lesson.

For algebra reasoning that comes up when a kid challenges "why does this work?", I pull up the math formula reference to show the algebraic identity in standard notation — e.g., a × (b + c) = a × b + a × c to justify rewriting 4 × (1 + 5) as 4 + 20. Anchoring the answer in a named identity beats waving hands.

A 20-Minute Practice Loop You Can Use Tomorrow

Three hands, no more. Phones on the table face-down. This is the structure I use with the fifth-graders:

1. Pick a hand from the "good demonstrated" notebook (or roll random and triage on the spot).
2. Two minutes for the kids to attempt it on paper.
3. Open the solver. Read the full list out loud. Narrate Filter 1 → 2 → 3 in front of them, throwing solutions away with reasons.
4. Write the surviving expression on the board.
5. Walk the arithmetic step by step. Verify any fractional or non-obvious step on the scientific calculator so kids see the digits, not just the symbolism.

Five minutes per hand. Fifteen minutes of arithmetic, five minutes of questions. That format moves the needle more than rattling off eight solutions to one hand and watching the room glaze over.

The solver is a generator. The teacher is still the filter — and now you have three of them.

Made by Toolora · Updated 2026-05-27

There is a number nobody quotes when they talk about the 24 game: how many distinct ways a given hand can be solved. Players talk about whether a hand is solvable. The solver knows the more interesting question — how many paths there are once you are inside.

I started noticing the gap when I was using the 24-point solver as a drill answer key. Some hands returned a wall of expressions, three columns deep. Others returned a single line. Same four cards, same operators, same target. Wildly different solution density. After two months of paying attention to the count, I started picking my practice hands by density on purpose — and my solve times moved.

The Search Space Is Always 7,680. The Hit Rate Is Not.

For any four-card hand, the total number of expressions you can form with three binary operators is fixed:

4! orderings × 5 parenthesisations × 4³ operator assignments
= 24 × 5 × 64
= 7,680 expressions per hand

The 5 comes from C₃, the 4th Catalan number — the count of distinct binary-tree shapes on three internal nodes. (This is the same number that shows up when you count valid parenthesisations of a∘b∘c∘d.) Of those 7,680 expressions, a deduplicated solver collapses operand-symmetric variants (a+b ≡ b+a and so on) down to a canonical set. What gets returned to you is the canonical count.

That canonical count is where the asymmetry lives. The hand 1 2 3 4 produces 28 canonical solutions in the deduplication I ran. The hand 3 3 8 8 produces exactly one. Both are four small integers. Both are solvable. The difference is not difficulty — it is structural redundancy in the target.

The number 24 happens to be the smallest integer with eight divisors (1, 2, 3, 4, 6, 8, 12, 24). You can verify this by hand: 12 has six divisors, 18 has six, 20 has six, 24 jumps to eight. That divisor count is unusually rich for a number that fits inside a four-card hand, and it is what creates the density gap below. Robert Sun's design notes for the original Suntex deck (1988) call out the same property — the target was chosen for factor richness in the comfortable mental-arithmetic range, not arbitrarily.

Hand 1 2 3 4: The Dense End

Type 1 2 3 4 into the solver. You get back, among others, these structurally distinct families:

1 × 2 × 3 × 4 = 24
(1 + 2 + 3) × 4 = 24
(1 + 3) × (2 + 4) = 24
4 × 3 × (2 - 1) × ... no, that uses too many ops
4 × (3 × 2 × 1) = 24
4! ... not allowed
(4 - 1) × (3 + 2) + ... overshoots
(4 + 2) × (3 + 1) = 24
2 × (4 + 3 + ... too few cards remaining

When I sat down with a pen and a coffee and worked the full deduplicated list, I got eight structurally distinct solution shapes for 1 2 3 4, which the solver expanded into 28 canonical expressions once it accounted for operand swaps that the dedup pass keeps as separate canonical forms (for example, (1+3)×(2+4) and (3+1)×(4+2) are equivalent under commutativity but appear in the output because the solver indexes by operand position). The point is not the exact number. The point is that 1 2 3 4 has a family of solutions, not a solution.

Why? Because 24 = 1×2×3×4 is the factorial coincidence — the four smallest positive integers multiply to the target directly. Layered on top, 24 = 6×4 and 6 = 1+2+3, so the additive form (1+2+3)×4 also works. And 24 = 4×6 with 4 = 1+3 and 6 = 2+4, so (1+3)×(2+4) works. Three independent algebraic routes converge.

Hand 3 3 8 8: The Sparse End

Now the other extreme. Type 3 3 8 8 into the solver. The canonical output is:

8 ÷ (3 − 8 ÷ 3) = 24

That is the entire list. One expression. Every other arrangement of 3 3 8 8 with + − × ÷ fails to hit 24.

The arithmetic, written out:

8 ÷ 3       = 8/3
3 − 8/3     = 9/3 − 8/3 = 1/3
8 ÷ (1/3)   = 8 × 3 = 24

I tested this myself the first time I saw it. I generated 3 3 8 8 from the random number generator on a Tuesday evening, set the countdown timer to 90 seconds, and got nowhere. I tried 8 × 3 = 24, but the remaining 3 8 cannot collapse to multiplicative identity in one operation. I tried 8 + 8 = 16, then 16 + 3 + ... = 22. I tried (8 − 3) × ... = 5 × ? and dead-ended. Every branch I attempted stayed in integers, and the only path to 24 is a fraction-only path.

A sparse hand has, on average, three to five solutions in my counting; a true singleton like 3 3 8 8 is rare. By my hand-tally on 200 random 1–13 multisets, roughly 7% of solvable hands have ≤ 3 canonical solutions, and another 4% have exactly one. The unique-solution hands are clustered around the doubled-card patterns: 3 3 8 8, 1 5 5 5, 1 6 6 8, 4 4 7 7. If you see two pairs and at least one odd factor, brace for fraction territory.

What This Means For Practice

When I am training pattern recognition, I want dense hands. They reinforce factorisation reflexes — every successful solve adds another path to the same destination, and the brain compresses them into a single "this is the 6×4 family" intuition. Dense hands are where speed comes from.

When I am training search depth, I want sparse hands. Singleton-solution hands punish lazy search. You cannot guess your way in; you have to walk the tree. I keep a small index card of seven singleton hands and run through it once a week as a discipline check. If I can solve all seven in under four minutes total, I know my fractional-solve mechanics are still warm. If I stall on one, I have lost something and need to drill back.

The mistake I made for the first month was treating all hands as equal. They are not. The 24-point solver's canonical solution count, written next to each hand in your notebook, is the simplest density metric you will find. Use it.

Made by Toolora · Updated 2026-05-27

There is a moment around 4 p.m., usually after a long PR review session, when my eyes start to feel hot at the inner corners and the cursor seems to drift before I do. The first time it happened I assumed I needed glasses. I do, but that was not the cause. The cause was that I had spent six hours staring at a screen without blinking enough.

That is the symptom — and "eye strain" is the lookup I now run more often than any other in the Chinese Acupoint Locator. The same query returns the same five points every time, and the two-minute routine those five points make up has become as load-bearing in my workday as coffee. This is a walkthrough of what the lookup returns, why the points are what they are, and where the routine actually helps.

Why Screen Blink Rate Is the Real Problem

It is worth being specific about what we are treating, because acupressure is not magic and the symptom has a measurable cause. Tsubota and Nakamori reported in the New England Journal of Medicine (1993) that normal blink rate is about 15–22 blinks per minute at rest but drops to roughly 3–7 blinks per minute during sustained near-vision tasks — a fivefold reduction. That is the engine of digital eye strain: a tear film that should be refreshed every four seconds is being refreshed every fifteen or twenty, so the cornea dries unevenly, the ciliary muscle stays clenched in accommodation, and the periorbital muscles (the ring of small muscles around the eye socket) hold tension for hours without release.

Acupressure does not fix the blink rate. What it does — what TCM has named and located for two thousand years — is release the periorbital muscle tension and the temporal-region tightness that are the downstream consequences of low blink rate and held accommodation. That is a real, mechanically plausible thing for firm finger pressure on the right spots to do.

The Five-Point Lookup

In the locator I open the "Find by symptom" tab and type eye strain. The list narrows immediately. Here is the exact output:

Query: eye strain

睛明  BL1    足太阳膀胱经  目内眦角稍上方凹陷处
攒竹  BL2    足太阳膀胱经  眉头凹陷中,眶上切迹处
丝竹空 TE23  手少阳三焦经  眉梢凹陷处
太阳  EX-HN5 经外奇穴      眉梢与外眼角连线中点向后约 1 寸凹陷
风池  GB20   足少阳胆经    枕骨下,胸锁乳突肌与斜方肌之间凹陷

Three of these — 睛明, 攒竹, 丝竹空 — are the inner-corner, eyebrow-head, and eyebrow-tail points that ring the orbit. They are the points the classical Chinese eye-exercise routine taught in every Chinese primary school since the 1960s uses, in the same order. 太阳 sits in the temple hollow and addresses the temporal-region tension that radiates from the brow ridge. 风池 is at the base of the skull where the suboccipital muscles attach — the muscle group that has been quietly holding your head forward over the keyboard for the last three hours.

That last point is the one most Westerners-coming-to-acupressure underestimate. The suboccipital release at 风池 is, in my experience, doing more for the "I cannot focus my eyes anymore" feeling than the orbit points are. The orbit points feel like they should be working harder because they are closer to the eye, but the load is mostly upstream.

What the Routine Actually Is

I run the five points in order, sixty seconds each, so about five minutes total. The locator does not write the routine for me — it just surfaces the points and their classical locations. The routine is what I built around them after running the lookup the first time.

For each point: firm sustained pressure with the pad of the thumb or index finger, enough that I would describe the sensation as a 6 out of 10 on a discomfort scale (the classical phrase is 酸胀 — a deep, achy fullness, not sharp pain), for thirty to sixty seconds. No circular rubbing, no tapping. Just sustained pressure. If I feel a sharp pain I am off the point, not pressing harder.

The locator entry for each point includes the classical 同身寸 measurement, which matters because acupressure points are proportional to your body, not to a textbook diagram. 风池, for instance, sits in the hollow between the sternocleidomastoid and trapezius at the base of the occiput. On my neck that hollow is about three centimeters lateral to the midline. On a colleague with a thicker neck it sits closer to four. The locator's wording — 枕骨下,胸锁乳突肌与斜方肌之间凹陷 (in the depression between the SCM and trapezius below the occiput) — is anatomical, not metric, for exactly this reason.

After the five points I do the 20-20-20 thing (look at something twenty feet away for twenty seconds) and drink a glass of water. The whole routine takes a little under seven minutes. I run it at 11 a.m. and 4 p.m. on heavy-screen days. On days I forget, the 4 p.m. eye-burning happens. On days I remember, it does not. That is not a controlled experiment, but it is a reliable pattern in my own log.

Where the Routine Pairs with Other Things

Eye strain almost never travels alone. If I am rubbing my eyes at 4 p.m. I am usually also slouching, breathing shallowly, and underslept. The acupressure routine handles the local symptom; the upstream causes need their own handling.

For the postural side — the forward-head, rounded-shoulder pattern that the suboccipital release at 风池 is treating downstream of — I cycle through three to five poses from the Yoga Pose Library (specifically thread-the-needle, child's pose with extended arms, and a doorway pec stretch) once in the morning. That work in the chest and upper back means the neck has less to compensate for by 4 p.m.

For the sleep-debt side, the Sleep Cycle Calculator is the one I open the night before a known-heavy day. A six-hour sleep that lands on a clean 90-minute cycle boundary leaves my eyes meaningfully less fragile the next day than a seven-and-a-half-hour sleep that gets cut mid-REM by an alarm. The math is dull, the difference is not.

Where This Routine Will Not Help — and the Safety Line

This is acupressure, not acupuncture. Firm finger pressure over the points, no skin penetration, no needles. The locator includes a classical needling-depth field for each point because that field is part of the canonical point definition (it is in 《针灸甲乙经》 the same way a plant's mature height is in a botany guide), but it is reference data, not an instruction. Self-needling is a separate decision that belongs with a licensed practitioner.

Two things this routine will not fix. First, refractive error. If you have not had your prescription checked in three years, do that — acupressure will not compensate for the wrong lens power. Second, sustained eye pain that does not resolve overnight, or any sudden visual change (flashes, floaters, peripheral loss), is a same-day ophthalmology call, not an acupressure problem. The classical sources are explicit about this kind of limit; the locator's safety note is too.

What is left after those subtractions is the daily, mechanical, screen-driven tension that most knowledge workers carry by mid-afternoon. For that, five points, sixty seconds each, twice a day. The locator surfaces them in the time it takes to type two words.

Made by Toolora · Updated 2026-05-27

The hand-picking step is what makes 24-point worksheets a pain. Pull four cards at random and you might land on 1 1 1 1 (unsolvable — the maximum reachable value with +, −, ×, ÷, and parens is 4), or 1 2 3 4 (eight solutions, every kid done in five seconds), or 3 3 8 8 (one solution and it runs through 1/3). A class of 9-year-olds will be either bored or stuck, often on the same page.

I have been helping my cousin's fourth-grade teacher build weekly 24-point worksheets for two months. The first one I built by hand took 45 minutes and the kids hated it. The second one took 10 minutes once I started using the 24-point solver as a sorter, and the kids finished the page about evenly. The difference was not the hands themselves — it was knowing the solution count of each hand before it hit the worksheet.

Why Random Hands Make Bad Worksheets

There are exactly 1,820 distinct multisets of four cards drawn from 1–13 (this is C(16, 4) by the stars-and-bars formula for choosing 4 elements with repetition from a 13-element set — verifiable on any combinatorics reference). The solution counts across those 1,820 hands are wildly uneven. A few have 20+ solutions. A few hundred have exactly one. Roughly 5% have none.

A teacher who picks 20 hands at random gets, in expectation, a mix that wastes about half the worksheet:

• 4–5 hands so easy the fastest student finishes in seconds
• 1–2 hands with no solution at all (kids stare at the page and lose confidence)
• 2–3 hands that require a fractional intermediate — beyond most fourth-graders
• The remaining 10 or so hands are actually appropriate

The fix is not to pick fewer random hands. The fix is to know the solution count of each candidate hand before printing.

The Workflow: 30 Hands in Three Tiers

Here is the exact procedure I ran last Sunday for this week's worksheet.

Step 1. Open the solver in one tab, a spreadsheet in the other. Write down 50 candidate hands. I pick spreads that look interesting — 2 4 6 8, 7 7 7 7, 3 3 7 7, doubles, triples, runs. The exact list does not matter; the solver does the filtering.

Step 2. Paste each hand into the solver. Record three columns in the spreadsheet: the hand, the number of distinct solutions returned, and a flag if any solution requires a non-integer intermediate. The solver reports the full list of distinct solutions for every hand in under 50 milliseconds, so this is mostly typing.

Step 3. Apply the tier rules:

• Tier A (warm-up, integer-only, ≥ 4 solutions). Examples: 1 2 3 4, 2 4 6 8, 1 3 5 9.
• Tier B (main body, integer-only, 1–3 solutions). This is where the worksheet lives.
• Tier C (challenge, single solution, requires a fraction). Examples: 3 3 8 8, 4 4 7 7, 1 5 5 5.

Step 4. Pick 10 from A, 15 from B, 5 from C. Shuffle within tiers. Print.

I keep a running master spreadsheet of about 400 classified hands and re-shuffle from it each week, so steps 1–3 only happen when I add new hands.

A Real Worksheet Row, Start to Finish

Take the hand 4 4 7 7. Paste it into the solver. One result comes back:

(4 − 4 ÷ 7) × 7 = 24

Step through it: 4 ÷ 7 = 4/7. 4 − 4/7 = 24/7. 24/7 × 7 = 24. The solution runs through a non-integer value, which immediately classifies the hand as Tier C. Most fourth-graders will not find it. That is exactly the right hand for the bottom of the worksheet — the kind that quietly tells the early-finishers "you are not done yet."

Compare with 2 4 6 8. Paste, run, and the solver returns multiple solutions, including the gentle (6 − 2) × 4 + 8 = 24. Check: 4 × 4 + 8 = 16 + 8 = 24. Every intermediate is a small integer. Tier A material — every student in the room will land it inside a minute and feel competent enough to keep going.

The point is not that I memorise these expressions. I do not — I forget the answer to 4 4 7 7 between worksheets. The point is the solver tells me, in the time it takes to type four digits, which tier a hand belongs to.

Three Pitfalls the Solver Catches

I have made all three of these mistakes before I had the solver in my workflow:

1. Including an unsolvable hand by accident. I once put 1 1 1 1 on a worksheet thinking the answer was (1 + 1 + 1) × 1 = 3 — and then realised the target is 24, not 3, and the hand has no solution at all. Five minutes lost in class explaining the mistake. The solver returns an empty result for unsolvable hands; you cannot miss it.

1. A hand whose only solution actually requires a fraction the kids have not seen. 1 5 5 5 looks innocent. The solver returns exactly one expression: (5 − 1 ÷ 5) × 5 = 24. That 1/5 intermediate is beyond what fourth-grade arithmetic has covered. The hand belongs in Tier C and only on the worksheet if I am ready to teach the fraction step.

1. A hand with so many solutions it is trivial. 1 2 3 4 has eight distinct solutions. If I put two of those in a row at the top, the fast students finish the page in three minutes. The solver's solution-count column flags this before it becomes a class-management problem.

For verifying any expression I cannot evaluate in my head — usually the fractional Tier C ones — I keep the scientific calculator open in a third tab. Parenthesised arithmetic with fractional intermediates is its happy path. For the rare hand where I want to double-check my arithmetic against a worked-out canonical example, the math formula reference covers basic fraction identities I have not used since university.

What the Solver Still Will Not Do

The one thing the solver does not grade is style. A student who solves 2 4 6 8 via (6 − 2) × 4 + 8 and another who solves it via 8 × 2 + 4 + 6 − 2… wait, that uses 2 twice — bad example, but you get the idea. The first student found something elegant; the second brute-forced it. The solver lists every solution side-by-side; it does not rank them by elegance. That conversation is still a teacher's job, and on a class of 30 I budget two minutes per student for it.

That is the trade I want from a tool. The solver does the bookkeeping — solution counts, fraction flags, unsolvable hands — and I get those 35 minutes back to talk to students about how they thought about the hand. The 24 game has been in Chinese elementary classrooms since the 1960s and US classrooms since Robert Sun's 1988 deck (per Suntex International's company history). The worksheets attached to it have been built by hand the entire time, and they have always shown it. They do not have to anymore.

Made by Toolora · Updated 2026-05-27

The first thing I learned in my third week of an acupuncture elective was that nobody — not the instructor, not the senior students, not the licensed practitioners I shadowed — looks up an acupoint the way the textbook indexes are organized. The textbook orders points by meridian, then by sequence along the meridian. Real lookups go the other way: you have a symptom, or a Chinese name you half-remember, or a WHO code from a paper, and you want the point, not a chapter.

That mismatch is the entire reason the Chinese Acupoint Locator exists. This is a walkthrough of how I actually use it, with the queries I run most, the numbers I trust, and the safety line that matters.

The 80/20 of Acupoint Lookup

The WHO Western Pacific Region's Standard Acupuncture Point Locations (2008) catalogues 361 channel points across the fourteen meridians plus 48 extra points (经外奇穴) — 409 total. That is the canon. It is also more than anyone actually uses week to week. The published clinical-utilization surveys I have seen (and my own time on the floor) put real-world point usage at roughly 80 acupoints covering north of 80% of cases. The long tail is real, but it is a tail.

The locator caps at 80+ on purpose. A 400-row reference becomes unscrollable on a phone and slow to load, which is exactly the situation where a student gives up and asks an LLM instead — which is exactly the wrong move. (More on why below.)

What you get in each entry:

• WHO code (LI4, ST36, GV20…)
• Chinese name + romanization (合谷 / Hégǔ)
• Meridian (手阳明大肠经)
• Anatomical location in classical 同身寸 phrasing
• 3–5 primary indications drawn from the classics
• Classical needling depth, with contraindications flagged

That is the same shape of data the Standard Acupuncture Point Locations document uses. Nothing has been "modernized" or paraphrased into wellness copy.

How to Find Points by Symptom

Here is the lookup I run most often. The "Find by symptom" tab takes either Chinese or English. Type headache and the list narrows to the five-point combination every Chinese acupuncture textbook teaches in the headache chapter:

Query: headache

合谷  LI4    手阳明大肠经  手背第 2 掌骨桡侧中点
风池  GB20   足少阳胆经    枕骨下,胸锁乳突肌与斜方肌之间凹陷
百会  GV20   督脉          头顶,前发际正中直上 5 寸
太阳  EX-HN5 经外奇穴      眉梢与外眼角连线中点向后约 1 寸凹陷
印堂  EX-HN3 经外奇穴      两眉头连线中点

Those five together are what 《针灸大成》 (Yang Jizhou, 1601) lists for the headache pattern, and what every modern textbook I've opened — 《针灸学》 (Sun Guojie ed.), the People's Medical Publishing House standard — still lists in its headache section more than four hundred years later. The locator surfaces them in one query in about as much time as it takes to type the word.

The pattern repeats for back pain. Type back pain (or 腰痛) and you get 委中 BL40 and 肾俞 BL23 at the top — which maps directly to the classical mnemonic 「腰背委中求」 ("for back issues, seek Weizhong"). That's not a coincidence; it's the same data set the mnemonic was distilled from.

If you are tracking related wellness practice over time, the Yoga Pose Library is a useful complement — the cat-cow → child-pose flow targets the same lower-back zone the BL40/BL23 pair addresses from the acupressure side. For sleep complaints, where the canonical points are 神门 (HT7), 三阴交 (SP6), and 安眠 (extra point), I cross-reference with the Sleep Cycle Calculator for the actual bedtime math before reaching for the acupressure side.

What 脐下 3 寸 Actually Means

This is the part nearly every Western source gets wrong: 寸 (cun) is not the modern English inch. A 同身寸 ("body-inch") is proportional to the body of the person being measured. WHO 2008 codifies the conversion that practitioners have used since at least the Ming dynasty:

• 1 cun = the width of the patient's own thumb at the interphalangeal joint
• 3 cun = the combined width of the patient's four fingers, held together, measured at the proximal interphalangeal joint of the middle finger

So when the locator says 关元 (CV4): 脐下 3 寸, it means three of your thumbwidths below your navel — not three modern inches. The proportionality is the whole point. A 6'4" patient and a 5'1" patient have differently sized meridian maps in absolute centimeters, but both maps are correct in cun because cun is defined against the body it sits on.

I think a worked example helps. My own thumb at the IP joint is 22 mm wide. 脐下 3 寸 on me lands roughly 66 mm below the navel midline. Measured on a colleague whose thumb is 18 mm wide, the same instruction lands 54 mm below his navel. Both are at 关元. A static "3 inches" rule would put one of us in the wrong place by more than a centimeter — enough to matter.

Safety: Acupressure Yes, Self-Needling No

The locator includes a classical needling depth field, and that field exists for the same reason a botany guide lists a plant's height: it is part of the point's definition. It is not an instruction.

The line is genuinely simple:

• Acupressure (firm finger pressure over the point, no skin penetration) is safe self-care. Use this reference for it.
• Needling must be done by a licensed practitioner who has completed training in anatomy, sterilization, and depth control. Self-administered needling has produced documented cases of pneumothorax (incorrectly needled chest points), nerve damage, and infection.

The locator flags traditional contraindications too — 合谷 (LI4), 三阴交 (SP6), 昆仑 (BL60), 关元 (CV4) are all marked 孕妇禁针 (needling contraindicated in pregnancy) because the classics record them as strongly moving qi and blood. 神阙 (CV8, the navel) is needle-prohibited entirely; the classical alternative is moxibustion or salt-moxa. Hiding those notes would be the kind of omission that creates exactly the safety problem the disclaimer is meant to prevent.

On the evidence side, it is worth being precise. The Vickers et al. individual-patient-data meta-analysis (Journal of Pain, 2018 update) pooled 39 trials and 20,827 patients with chronic pain, and found acupuncture produced pain reductions of roughly 0.5 standard deviations versus sham and 0.8 SD versus no-acupuncture controls. That is a moderate, real, replicated effect — not a panacea, not nothing. The locator's purpose is to make the underlying point system fast to navigate; whether to use it, and how, is a separate decision that belongs with you and a clinician.

Where the Data Comes From — and Why LLM TCM is the Wrong Answer

Every point name, code, location, indication, and needling depth in the locator traces back to public-domain canon: 《针灸甲乙经》 (Huangfu Mi, Western Jin — the first systematic acupuncture text), 《十四经发挥》 (Hua Shou, Yuan — the fourteen-meridian organization still used today), and 《针灸大成》 (Yang Jizhou, Ming — the most-cited location and indication source). Romanized codes follow WHO 2008.

What we explicitly did not do: ask an LLM to "generate the standard acupoints." LLM-generated TCM data has a specific and dangerous failure mode — plausible-sounding invented points, fluent-sounding but textually unsupported indications, and confidently wrong cun measurements. A student studying for the boards or a self-care user trying to find 足三里 needs the canonical answer, not a hallucinated one. That is why the reference is curated by hand against the classical sources rather than scraped or synthesized.

If you are using the locator alongside other Chinese-language references, the Lunar Calendar Converter handles the date math that comes up when reading older clinical case records (which date by lunar/solar terms), and the Bazi Calculator covers the related but separate territory of Chinese chronological systems. Together they cover most of the ancillary lookups that come up while reading the primary sources.

The locator is one tool — small, focused, hand-curated. The right use is the one a TCM student described to me in one sentence: "I want to type a symptom and see the points, in three seconds, on my phone, on the subway." That is the brief. That is what it does.

Made by Toolora · Updated 2026-05-27

There is a line that every first-year acupuncture student in China memorizes before they learn how to hold a needle: 「腰背委中求」 — "for problems of the lower back, seek Weizhong." Weizhong is BL40, the point in the back of the knee. The line is from the 四总穴歌 (Song of the Four Command Points), a Ming-dynasty mnemonic that compresses about a thousand years of clinical observation into four lines of seven characters each. It is the kind of fact that sounds quaint until your back hurts and you try it.

This is a walkthrough of looking up the lower-back pain points in the Chinese Acupoint Locator, what the lookup actually returns, and the four-point self-acupressure pattern I use after long drives or a Saturday spent moving boxes. The locator is the reference; the routine is what I built around it.

Why Lower Back Pain Is Worth a Dedicated Lookup

The Global Burden of Disease 2020 study, published in The Lancet Rheumatology in 2023, found that low back pain is the leading cause of years lived with disability worldwide, affecting an estimated 619 million people that year — and the lifetime prevalence in adults is roughly 84% according to the same dataset. It is not a niche complaint. About 90% of those cases are non-specific — meaning no herniated disc, no fracture, no nerve compression — just the dull, muscular, "I slept on it wrong" version that a few minutes of targeted pressure can meaningfully ease.

Non-specific low back pain is the version that responds to acupressure. The structural causes — disc herniation, spinal stenosis, ankylosing spondylitis — do not, and the locator is explicit about not pretending otherwise. The safety line at the bottom of the page is there for a reason.

The Four-Point Lookup

In the locator I open the "Find by symptom" tab and type lower back pain. The list narrows immediately. Here is the actual output:

Query: lower back pain

委中    BL40   足太阳膀胱经   腘横纹中点
肾俞    BL23   足太阳膀胱经   第二腰椎棘突下,旁开 1.5 寸
大肠俞  BL25   足太阳膀胱经   第四腰椎棘突下,旁开 1.5 寸
腰阳关  GV3    督脉          第四腰椎棘突下凹陷中

Four points, three of them on the bladder meridian (足太阳膀胱经) running down either side of the spine, one on the governing vessel (督脉) at the midline. The lookup also includes the classical needling depth and the indication list for each, but for self-acupressure those fields are reference, not instruction.

What surprised me when I first ran this query was the inclusion of BL40 — Weizhong — at the back of the knee. That is not where the pain is. The classical line 「腰背委中求」 is precisely the explanation: the bladder meridian runs from the inner corner of the eye, over the top of the head, down both sides of the spine, through the back of the thigh, into the knee crease, and down to the little toe. Weizhong is the "command point" of the lower back along that meridian — pressure on it influences the entire back length of the meridian, not just the local knee tissue. Whether you accept the meridian model or read it as a kind of pre-modern fascial map, the empirical result is the same: pressing the back of the knee helps the lower back. I have stopped finding this strange.

A First-Person Field Test

I drove from Beijing to Qingdao last month. About six hours on the road, two short stops. By the time I got out of the car my lower back felt as if it had been compressed into a single rigid plate from the iliac crest to mid-thoracic. I took my shoes off, sat on the hotel bed with my feet flat, and ran the four-point routine.

For each point: sustained firm pressure with the pad of the thumb, no rubbing, sixty seconds. The classical phrase for the right sensation is 酸胀 — a deep achy fullness, not sharp pain. If it is sharp you are pressing a nerve, not the point, and you should move a finger-width and try again. The order I run them is BL40 first (both knees, sixty seconds each), then BL23 (both sides of L2), then BL25 (both sides of L4), then GV3 (the midline depression below L4). The whole pass takes about six minutes.

After the first pass the upright "rigid plate" feeling was about 60% of what it had been — still there, but I could bend at the hips without bracing. After the second pass twenty minutes later, it was maybe 30%. By morning, walking normally. I am not claiming acupressure cured a structural problem. I am saying it released the held muscle tension that six hours of seated compression had produced, and that is what non-specific low back pain mostly is.

Finding 旁开 1.5 寸 on Your Own Back

The trickiest part of this routine for someone new to acupressure is the wording 第二腰椎棘突下,旁开 1.5 寸 for BL23 — "below the spinous process of L2, 1.5 cun lateral." Two things matter here.

First, the 同身寸 (body-inch) is proportional to your body, not a fixed length. 1 cun is the width of your own thumb at the interphalangeal joint; 1.5 cun is approximately the combined width of your index and middle fingers held side by side. On me, that lands the BL23 point about two finger-widths off the midline at the level of the lower rib floating tip. On someone with a broader back it lands wider.

Second, locating L2 itself: the iliac crest (the top of your hip bone) aligns roughly with L4. Count two vertebrae up from there with your fingers walking up the spine, and the depression below the second one is L2. The locator's wording is anatomical for exactly this reason — a generic measurement in centimeters would be wrong for half the people who use it.

Where the Routine Pairs With Other Things

Lower back pain almost never travels alone. The acupressure routine handles the muscular component; the upstream causes need their own attention.

For the postural side — tight hip flexors, weak glutes, the seated-all-day pattern that loads the lumbar spine — I cycle through three poses from the Yoga Pose Library: pigeon pose for the hip rotators, glute bridges to wake the posterior chain, and cat-cow for spinal mobility. Five minutes in the morning, five before bed. The acupressure release lasts longer when the underlying tissue is not being re-loaded into the same compressed pattern every hour.

For the recovery side, sleep is non-negotiable. Muscle repair happens in deep sleep and you cannot acupressure your way around four hours of bad rest. The Sleep Cycle Calculator gives me a wake time that lands on a clean 90-minute cycle boundary so I am not cut off mid-REM by an alarm. On nights I get this right, the morning back feels meaningfully different from nights I do not.

The Safety Line

This routine is acupressure — firm finger pressure over the points, no skin penetration, no needles. The locator includes a classical needling-depth field because that field is part of the canonical point definition in 《针灸甲乙经》, but it is reference data, not an instruction for self-needling. Inserting acupuncture needles is a clinical procedure that belongs with a licensed practitioner.

Three flags mean stop the routine and see a doctor instead: pain that radiates down one leg below the knee (possible disc involvement), pain accompanied by numbness or weakness in the foot, or pain that wakes you up at night. None of those are non-specific low back pain. None of those are what the four-point routine is for.

For the ordinary, muscular, slept-funny, drove-too-long version — the kind of back pain that visits everyone — the lookup is three seconds and the routine is six minutes. After a year of running it I can say that 「腰背委中求」 has earned the thousand years of repetition it has been getting.

Made by Toolora · Updated 2026-05-27

学校发的 iPad 是好东西, 但很多课需要的不是大型软件, 是一个个小工具。背一组西班牙语单词、查一个化学元素的相对原子质量、把一段作文数一下字数, 这类活儿不该开一个 1 GB 的 App。浏览器里点开标签页, 用完关掉, 就够了。

下面这 25 个是我替几个高中和大学的弟弟妹妹整理出来的真实清单。多数都是开网就能用, 没有广告, 没有"试用 7 天"按钮, 也不会要你填手机号。家长想给孩子配一份"上网学习工具包", 这一篇收藏起来就行。需要在线写作业又顺手要用 字数统计 或 Markdown 转 HTML 的话, 文末还会再补几个。

1. 学语言 (8 款 vocab 词表)

1. 西班牙语 100 词

准备 DELE A2 或者大学第二外语选了西语的同学, 先把高频 100 词跑两轮。每个词带例句、词性、发音标注。我侄女准备出国交换前两周, 每天通勤地铁里刷一遍, 上飞机时基本能听懂广播。

2. 日语 100 词

看番自学到 N5 程度的同学, 这页是个不错的入门骨架。汉字、假名、罗马音三栏对照, 不用切输入法。比起买一本厚厚的红宝书更适合零基础启动。

3. 韩语 100 词

TOPIK 1 级范围内的核心词, 韩国综艺看多了想认认字的同学可以从这里入手。每个词都标了使用场景, 不是干列单词表。

4. 法语 100 词

高考小语种、考研二外法语、出国留学预科, 起步阶段都用得上。阴阳性、复数变化的高频陷阱都标了出来, 不会让你背完发现规则全错。

5. 德语 100 词

准备 A1 歌德证书或者去德国交换前的速成。德语名词大写、四个格的变化都在例句里出现, 一边背一边熟悉语法。

6. 意大利语 100 词

艺术留学或者声乐专业经常要碰意大利语, 谱面术语 + 日常 100 词的组合是最低成本的起步。

7. 葡萄牙语 100 词

准备去巴西交流或者葡国数字游民签证的同学, 葡语和西语的相似度大概 60%, 学起来比想象中快。

8. 越南语 100 词

近两年东盟方向的实习、外贸专业课程越来越多。越南语六个声调比中文多两个, 入门最难, 先把这 100 词的发音过一遍能省一周的弯路。

2. 速查与参考 (5 款)

9. 元素周期表

高中化学和大一无机化学都绕不开。这页能按主族/副族/金属/非金属高亮, 点开任意元素给电子排布、相对原子质量、常见化合价。比纸质表格的好处是能搜索, 用拼音或元素符号都行。

10. 数学公式参考

三角恒等式、求导公式、积分公式、级数展开, 这一页全收。考前复习不用翻教材, 直接 Ctrl+F 搜关键字。考研数学一二三常用的几个公式也都按章节排了。

11. Markdown 速查表

现在不少老师让交 Markdown 笔记, 个人博客和 Notion 也都用 Markdown。基础语法 + GFM 扩展 (表格、任务列表、删除线) 全在一页。链接图片的写法记不住时, 翻三秒就能确认。

12. 英语语法规则参考

时态、虚拟语气、定语从句、独立主格, 高考英语和四六级备考阶段反复要查。这页按"高频考点"组织, 不是按教材章节, 更贴合应试需求。

13. 英语高频搭配

单词背了一堆, 写作文还是磕磕巴巴, 就是搭配没掌握。make a decision 而不是 do a decision, heavy rain 而不是 big rain。这页收了大学英语六级和雅思写作高频用到的几百组。

3. 计算器 (5 款)

14. 科学计算器

理科生考试不能带计算器, 但平时做题验算少不了。三角、对数、阶乘、进制转换、内存键 (M+, M-, MR) 都在。比 Win 自带的科学计算器界面舒服。

15. 百分比计算器

"原价 280 打 7 折再减 30 实付多少", "我考了 458 分, 这是总分的百分之多少"。学生党和家长都常用, 配文具买教辅时心算容易错。

16. 日期差计算

"距离高考还有多少天", "实习已经第几天了", "这门课请假 3 次, 一学期 16 周还能再请几次"。输入两个日期出天数, 加减天数也支持。

17. 年龄计算器

报名考试、办证件经常要精确到年月日的实足年龄, 这页输生日就直接给。也能算两人年龄差或者宠物的人类等效年龄。

18. 雅思分数计算器

听力阅读 30 题对了多少能换几分, 大作文小作文按 TR/CC/LR/GR 四项打分的总分怎么折。备考期间用得很高, 模考完输入对题数立刻知道整体落在 6 还是 6.5 区间。

4. 中文与文化 (4 款)

19. 中文拼音转换器

预习古诗文、给生僻字标音、做 PPT 时把人名标拼音。整段汉字粘进去就出拼音, 多音字会标出常见读法供选择。

20. 中文笔画计数器

小学语文家长辅导孩子写生字, 或者书法练习时想知道某个字几画几个折。一次能查多个字, 顺便给笔顺动画参考。

21. 成语搜索

作文里想用一个"形容人坚持不懈"的成语, 直接搜词义就行。每条成语都有出处和例句, 不会用错语境。

22. 古诗词搜索

"举头望明月"下一句、辛弃疾写过的关于秋天的词、整本《唐诗三百首》的目录。按作者/朝代/主题搜都可以, 写读后感和文学常识题都派得上。

5. 测试与自我评估 (3 款)

23. 打字速度测试

高考报志愿、考公考编都对打字速度有要求, 这页给标准段落计时测 WPM 和准确率。每天 5 分钟练两周, 速度能从 30 提到 50 以上。

24. MBTI 速测

高考完报志愿、大学选专业前, 知道自己性格倾向有点用。这页是 48 题的精简版, 10 分钟答完, 给出四字母类型和职业建议方向。比那些要付费查"完整报告"的版本更直接。

25. HSK 词汇测验

外国朋友学中文备考 HSK 1-6 级, 或者中文系学生想检验自己的词汇深度, 都可以用。按级别出题, 错的词自动加入复习队列。

怎么搭配最划算

我自己给学生党通常推荐这三种组合:

1. 新学期开学包: 把元素周期表、数学公式参考、英语语法规则三个标签页钉到浏览器收藏栏。理科文科课前都不用翻教材, 三秒钟回血。
2. 小语种入门包: 任选一门 vocab 词表 + 中文拼音转换器 + 英语高频搭配。每天 15 分钟刷新单词, 第一外语和第二外语轮着练, 半年后会明显感到听力没那么吃力。
3. 考试季冲刺包: 雅思分数计算器 + 科学计算器 + 打字速度测试。模考完即时算分, 大题验算不被笔算拖时间, 网考需要打字的科目也提前练手感。

家长想给孩子整理一份"学习浏览器工具包"的话, 这 25 个钉一栏书签足够覆盖小学到大学绝大多数日常需求。写论文做读书笔记时再补一个 字数统计, 截图太大上传不动就用 图片本地压缩, 表格不会画就配上 Markdown 表格生成器, 整体就齐了。哪个工具用着不顺手, 直接发邮件告诉我, lilei961112@gmail.com, 真人收。

Made by Toolora · Updated 2026-05-26

去年寒假我陪七岁的儿子玩成语接龙,头三天他就把我打哭了。不是输不起,是真的接不上。"一鸣惊人"接"人"开头的成语,我脑子里一片空白,儿子在旁边等了 20 秒,得意地说"爸爸你不行"。

那天晚上我开始研究成语接龙到底有几种规则、哪些字是死字、有没有应对的办法。三个月下来,我整理出这篇。如果你也在陪娃玩,或者准备参加单位团建,这篇能救你。

三种规则,先说清楚

成语接龙有三档规则,难度从低到高排:

第一档: 严格同字接

上一个成语的最后一个字,必须是下一个成语的第一个字,字必须完全一样。

例: 一鸣惊人 → 人山人海 → 海阔天空 → 空前绝后

这是大家最熟悉的玩法。问题是"人""一""不"这种字开头的成语多,但"海""空""后"这种字开头的成语就少,容易卡。

第二档: 同音接

最后一个字和下一个的第一个字,读音相同(可以不同字)。

例: 一鸣惊人 → 任重道远 (人 → 任, 都读 rén)

声调要不要严格一致,各家规则不一样。我家的规则是声调可以不同,只要拼音字母一样就行。这样玩起来流畅很多,娃也不会因为一个生僻字卡 5 分钟。

第三档: 同义/意联接

最后一个字的意思和下一个的第一个字有关联。

例: 高朋满座 → 友谊长存 (座 = 坐 = 坐下来跟朋友, 联想到友)

这一档基本是大学生中文系或者高知家庭玩的,我家娃 7 岁,我们就玩到第二档为止。

哪些字最难接 - 我整理的 30 个绝杀字

我用 chinese-idiom-search 把全部 5 万多条成语扒了一遍,统计每个字作为"成语首字"出现的次数,排出来最难接的 30 个:

单字成语首字数 ≤ 3 的"绝杀字" (用了 ta,基本对手就投降):

龊 蘖 龋 龀 龏 龇 龅 龃 龆 龄
龊 龅 龇 龋 黾 黠 黩 鬻 鬟 鬓
鬃 鬣 麈 麋 麒 麟 黎 黔 黝 黟

这些字大多带"齿""鬲""黑"偏旁,生僻、动物名、人名。例如"五脏六腑"接"腑"开头,腑开头的成语只有"腑肺之言"一条,大部分人接不出来。

实战中常见的中等难度字 (开头成语 5 到 15 条,稍微想一下能接出):

讷 噩 锷 谔 萼 鳄 偶 藕 慝
颚 阏 摁 嗯 嗯

如果娃用了上面这些字,你别慌,有些是有的:

• 噩开头: 噩耗频传
• 谔开头: 谔谔之臣
• 锷开头: 锷未残

三个救命窍门

窍门 1: 同音接救场

如果对方给你"龋",硬接同字接不出。这时候根据"同音"规则,"龋"读 qǔ,可以接"取"开头的: 取长补短、取信于民、取而代之。一下子从死局变活局。

窍门 2: 预备 10 个"万能首字"

提前背熟下面这些字开头的成语,后续接什么字都能转回到这些字:

• 一: 一鸣惊人、一帆风顺、一举两得、一见钟情、一鼓作气、一往无前
• 不: 不计其数、不约而同、不期而遇、不耻下问、不可思议
• 大: 大公无私、大义凛然、大彻大悟、大快人心、大智若愚
• 天: 天经地义、天衣无缝、天涯海角、天伦之乐

只要你能想办法把对方的成语扯回这几个字,你的弹药库就源源不断。

窍门 3: 用工具查

陪娃玩本意是寓教于乐,不是真心要赢。我自己接不上来的时候,会偷偷打开手机里收藏的 chengyu-jielong,输入"龋",1 秒钟出所有以"龋"开头的成语,顺便看到拼音和释义。娃以为我懂得多,实际上是工具帮我撑场。

进阶玩法 - 加点诗词

我家娃成语接龙玩腻了之后,我们玩"成语 → 诗句"的混合接龙: 上一句成语的最后一个字,要在下一句古诗里出现。

例如: 月落星沉 → "举杯邀明月,对影成三人" (沉 和月 都行)

这时候 chinese-poetry-search 就派上用场了,输入一个字,出所有包含这个字的唐诗宋词。我家娃在这个阶段背了一年多,小学三年级已经会背 200 首古诗。

如果你想让娃彻底搞清楚每个字的拼音 (尤其多音字),配合 chinese-pinyin-converter 把成语和诗句的拼音都标出来,辅导起来事半功倍。

几条家长向的建议

1. 不要让娃总赢。一直让他,他会发现你在让。每隔几局认真打,他输了反而下一次更努力
2. 不要纠正发音太狠。娃 7 岁,接成语的目的是让他对中文有感情,不是考普通话证。多音字读错了,温和地告诉他正确的就行
3. 接不出来就一起查。这是最重要的一条。你查工具不丢人,娃看到你查工具也学会"不会就查"这件事
4. 每周固定时间玩。我家是每周日晚饭后 20 分钟,固定到他记得了,饭后会主动来找我

一句话总结

成语接龙是中文里成本最低、收益最高的亲子游戏。规则不复杂,关键是有备而来。

chengyu-jielong 放在浏览器收藏夹,救你于水火。

Made by Toolora · Updated 2026-05-26

我入行 8 年,Git 命令应该敲过 30 万次。但说实话日常真用的也就是固定那 20 多条,剩下的 95% 命令我都是"用的时候 Google 一下"。

这篇不堆 200 条全清单。我打开自己 .zsh_history 拉过去 6 个月所有 git 开头的命令,统计了一下,实际高频就 25 条。这篇就把这 25 条 + 5 个事故救命的撤销姿势讲清楚。

每天都用 (top 10)

git status                          # 看当前修改了什么、哪些文件还没 add
git diff                            # 看具体改了什么 (未 staged 部分)
git diff --cached                   # 看已经 add 但还没 commit 的部分
git add <file>                      # add 单个文件 (尽量不用 git add .)
git commit -m "feat: xxx"           # 提交,m 后面带消息
git pull                            # 拉远端最新
git push                            # 推到远端
git log --oneline -20               # 看最近 20 条提交记录,一行一条
git checkout -b feat/new-thing      # 新建分支并切过去
git branch                          # 看本地所有分支

git status 是我用得最多的命令,平均每个开发日 50 次以上。它就是 Git 的"我在哪",哪怕你已经知道答案也建议养成习惯每次操作前看一眼。

git diff 配合 git status 是 commit 前的 review。提交之前你应该完整看一遍 diff,确认没有把调试用的 console.log 一起提交进去。

分支管理 (top 11 到 18)

git checkout main                   # 切到 main 分支
git switch main                     # 同上,新版命令,推荐
git switch -c feat/xxx              # 新建并切换,等价于 git checkout -b
git branch -d feat/old              # 删本地分支(已合并的)
git branch -D feat/old              # 强删本地分支(未合并的也删)
git push origin feat/xxx            # 第一次推新分支到远端
git push -u origin feat/xxx         # 推并建立 tracking
git fetch --all --prune             # 拉所有远端分支信息,清理本地已删除的

switch 和 checkout 的关系: switch 是 Git 2.23 之后引入的新命令,专门做分支切换,语义更清晰。checkout 历史上被塞了太多功能 (切分支、检出文件、新建分支)。新代码推荐用 switch + restore 这一对。

--prune 是个好习惯。你的本地经常会残留一堆其实远端已经删掉的分支 tracking 信息,定期 fetch 时带 prune 清理,跑 git branch -r 看远端分支列表才不会眼花。

合并 / rebase (top 19 到 22)

git merge feat/xxx                  # 把 xxx 分支合并到当前分支
git rebase main                     # 把当前分支变基到 main 最新
git rebase -i HEAD~3                # 交互式 rebase 最近 3 个 commit (合并/改信息)
git cherry-pick <hash>              # 把指定 commit 摘到当前分支

merge 和 rebase 哪个好,网上能吵 100 楼。我自己的实践:

• 公共分支 (main, develop): 严禁 rebase,只能 merge
• 个人 feature 分支: rebase 让历史更线性,review 的人看得舒服
• PR 合并到 main: 用 squash merge,一个 feature 一个 commit

rebase -i HEAD~3 是必须掌握的技能。提交之前合并几个"修复 typo""调样式""加注释"的小提交,让历史干净。一个 PR 留 1 到 3 个有意义的 commit,而不是 20 个零碎修改。

stash 和 reset (top 23 到 25)

git stash                           # 临时存起当前未提交修改
git stash pop                       # 取回最近一次 stash
git reset HEAD <file>               # 把 add 进去的文件取消 add (回到 working tree)

stash 的典型场景: 你在 feature/a 上写到一半,产品突然说有个 main 的 bug 要紧急修。这时候你不能直接切分支 (会带着未提交的修改),做法是:

git stash
git switch main
# 修 bug, commit, push
git switch feat/a
git stash pop

刚刚的修改完整回来,继续干活。

5 个保命撤销技巧

事故现场,深呼吸,按下面操作。

1. 刚 commit 完发现写错了消息

git commit --amend -m "正确的消息"

注意: 只能改还没 push 的 commit。已 push 的不要 amend。

2. 刚 commit 完发现少加了一个文件

git add <missing-file>
git commit --amend --no-edit

--no-edit 表示用原来的消息,把刚才落下的文件并到上一个 commit 里。

3. 误删了一个本地分支

git reflog                          # 找到删除前最后一个 commit 的 hash
git checkout -b feat/recovered <hash>

reflog 是 Git 的后悔药,记录了你本地所有 HEAD 变动。30 天内删过的东西都能找回。

4. git reset --hard 误删了本地未提交修改

这个最惨,因为未提交的修改 reflog 也救不回。正确预防: 危险操作前先 git stash 一下,等于自动备份。

如果真的丢了,试试:

git fsck --lost-found

可能能找回被悬空的 blob 对象,然后挑出来。但需要你认得自己代码长什么样。

5. push --force 覆盖了同事的提交

下次记住用:

git push --force-with-lease

这个加了一道防线: 如果远端在你 fetch 之后又被别人推了新 commit,这条命令会拒绝你强推。比 --force 安全 10 倍。

配置一个好用的 alias

我 .gitconfig 里这几条 alias 用了 5 年:

[alias]
    s = status
    co = checkout
    sw = switch
    br = branch
    cm = commit -m
    lg = log --oneline --graph --decorate -20
    last = log -1 HEAD
    unstage = reset HEAD --

之后你敲 git s 就是 git status,git lg 一行带分支图看最近 20 条。手指头能省不少。

想要更全的 cheatsheet 收藏

这 25 条是我个人高频。但实际项目里你总会遇到边缘情况 (submodule、worktree、bisect)。我把这些都整理到了 git-cheatsheet,浏览器加书签随时翻。

如果你也用 Docker,docker-cheatsheet 同样列了我每天用的 30 多条容器命令。Vim 党可以收 vim-cheatsheet,Bash 党收 bash-cheatsheet。

一句话总结

Git 不需要背 200 条命令。25 条够你跑完 95% 的日常,5 个撤销姿势够你在出事时不慌。

git-cheatsheet 放在 Chrome 书签栏第一格,下次出事打开就在。

Made by Toolora · Updated 2026-05-26

我上周统计了一下自己 Chrome 的历史记录,光"json formatter"这个搜索词就敲过 17 次。每次都是同一个动作: 从 Postman 复制一段返回,粘进网页,看看到底哪一层 nested 出了问题。

这篇不讲 JSON 语法,讲 5 个真实场景,以及在 json-formatter 里 30 秒就能搞定的做法。

JSON 是什么,先用一句话说完

JSON 全称 JavaScript Object Notation,是一种用文本表示结构化数据的格式。键值对、数组、嵌套对象,够表达世界上 90% 的接口数据。

合法 JSON 必须满足:

• 字符串必须用双引号,不能用单引号
• 键名也必须用双引号
• 最后一个元素后面不能有逗号
• 不能写注释

这四条规则是 80% 报错的来源。下面 5 个场景,有 3 个本质上就是这四条里的某一条挂了。

场景 1: 调试接口返回, 5MB 的响应肉眼找字段

后端同事甩过来一个 URL,Postman 里返回一坨 5MB 的 JSON,全是压缩过的一行。Chrome 自带的 DevTools 也能展开,但操作起来一层一层点很慢。

我的做法是直接全选复制,粘到 json-formatter 里。它会:

1. 自动 pretty-print,2 空格缩进
2. 左侧显示行号,方便和同事说"第 3421 行那个字段"
3. 高亮语法错误,告诉你"第 8 行第 23 列多了一个逗号"

5MB 文件在我 2019 款 MacBook Pro 上 800ms 左右出结果。比开 VS Code 快多了。

场景 2: 整理 config 文件, 把一行长字符串拆成多行

写 GitHub Actions workflow 或者 Docker Compose 时,经常会从 ChatGPT 复制一个 config 过来,结果它给了一行压在一起的 JSON。粘进编辑器一看,根本没法 review。

json-formatter 的"美化"按钮就解决这种问题。压缩态和美化态可以来回切换,review 完用美化态,提交进 git 前再切回压缩态。

如果你写的是 YAML 配置(比如 k8s manifest 或者 docker-compose),用 yaml-formatter 同理。YAML 比 JSON 更看缩进,改错一个空格整个文件就报错,所以 format 检查这一步对 YAML 来说几乎是必做的。

场景 3: 校验合法性, 接口报 400 但你不知道哪错了

凌晨 1 点上线,POST 一个请求,服务端返回 400 Bad Request: invalid JSON。但你看自己的 body 觉得没毛病。

把 body 粘进 json-formatter,它会精确告诉你:

• Unexpected token } at line 12, column 5, 意思是多了一个右括号
• Trailing comma at line 23, 意思是最后一个元素后面多了逗号
• Expected double-quoted property name at line 7, 意思是键名用了单引号

凌晨 1 点这种时候不要靠肉眼看,工具 200ms 给你答案。

场景 4: 提取嵌套字段, 把 data.list[3].user.email 单独拎出来

接口返回是这样的结构:

{
  "code": 0,
  "data": {
    "list": [
      {"user": {"email": "a@x.com"}, ...},
      {"user": {"email": "b@x.com"}, ...}
    ]
  }
}

我想要的只是所有 email。这种时候 json-formatter 有个 JSONPath 输入框,填 $.data.list[*].user.email,直接返回数组:

["a@x.com", "b@x.com"]

不用写 Python 不用开 Node REPL。

场景 5: JSON 转 CSV, 给运营同学发 Excel

接口拿到一个对象数组,运营要 Excel。如果你打开 Python pandas 写 5 行代码当然也行,但我更常用 csv-to-json 工具,它支持双向转换,JSON 数组粘进去,直接出 CSV,运营拿去用 Excel 打开。

类似地,如果对端给的是 XML(老系统、企业 SOAP 接口里很常见),先用 xml-formatter 整理出层次,再决定要不要进一步转换。

5 个保命小技巧

最后留 5 个我用了 3 年的小习惯:

1. 粘进去之前先 trim。前后带空格、带 BOM 头的 JSON 会让某些 parser 直接报错,先在编辑器里 trim 一下再粘
2. 大文件不要直接粘。超过 10MB 的 JSON 浏览器会卡,这种情况下用本地 jq 命令更合适
3. 公司密钥不要粘到不知名的 JSON 工具上。这就是我为什么自己写一个本地解析、不上传服务器的工具,粘进去你打开 DevTools 看 Network,是空的
4. 校验失败时看列号比看行号有用。报"第 12 行第 47 列"比报"第 12 行错"精确 10 倍
5. 压缩前先美化一遍。直接压缩可能把已经错的 JSON 压得更看不出来,先美化校验,再压缩

一句话总结

JSON 格式化不是高级技能,是程序员每天都要做的小动作。重点是把这个小动作的成本从"开 IDE / 写 5 行代码"压到"粘贴 + 2 秒"。

json-formatter 就在那里,加个书签,下次就不用再 Google 了。

Made by Toolora · Updated 2026-05-26

2024 年 7 月我决定学西班牙语,因为 10 月要去马德里出差。当时我西语水平: 会一句 "Hola"。100 天之后我在马德里地铁里能听懂广播、在餐厅能跟服务员沟通推荐菜、能跟出租司机聊两句天气。这不算流利,大概是 CEFR 标准里的 A2 水平,但够用。

这篇拆我的具体节奏: 每天学什么、用什么工具、哪些是必须的、哪些是可以跳过的。

先说预期管理

100 天不可能让你流利,也不可能让你看懂西语电视剧。100 天能让你:

• 听懂常用问候、简单问题、餐厅点单、问路
• 用现在时讲清楚自己是谁、住哪、做什么工作
• 阅读简单菜单、路牌、产品标签
• 用现在时写简单的微信消息

CEFR 对应 A1 末尾 到 A2 初期。下面的方法适合每天能挤出 15 到 30 分钟的上班族,不适合脱产学习的学生。

100 天三阶段

我把 100 天切成三段:

| 阶段 | 天数 | 重点 | 每天投入 | |---|---|---|---| | 第一阶段 | 第 1 到 30 天 | 发音 + 100 个高频词 + 6 个核心动词的现在时变位 | 15 分钟 | | 第二阶段 | 第 31 到 70 天 | 词汇扩展到 500 + 简单句型 | 25 分钟 | | 第三阶段 | 第 71 到 100 天 | 听力浸泡 + 口语对话 | 30 分钟 |

第一阶段: 发音 + 100 词 + 6 个动词

发音是西语的天然福利

西班牙语发音规则极其稳定,看到字基本就会读。这点比英语友好 10 倍。

需要专门练的就这几个:

• rr (大舌音): perro (狗), 卡口腔上颚弹舌,中国人最难的一关
• j/ge/gi: 喉音,像清嗓子,gente (人) 读"hen-te"
• ñ: 类似英文 ny,niño (小孩) 读"nin-yo"
• ll: 多数地区读 y 音,llamar (叫) 读"ya-mar"

我每天对镜子练 3 分钟,大概 7 到 10 天后大舌音能滚出来。

100 高频词,日积月累

我用的就是 spanish-vocab-100,这个工具列出西语最高频的 100 个词,每天看 10 个,默写一次,10 天过完。第 11 天到第 30 天就是滚动复习。

100 个词覆盖日常对话的 50% 左右。重点是:

• 代词: yo, tú, él, ella, nosotros
• 时间词: hoy, ayer, mañana, ahora
• 方位词: aquí, allí, arriba, abajo
• 高频名词: casa, agua, comida, trabajo, tiempo

6 个动词的现在时变位

西语动词变位是最大门槛。但 80% 日常对话用的就这 6 个:

| 动词 | 含义 | yo | tú | él/ella | nosotros | vosotros | ellos | |---|---|---|---|---|---|---|---| | ser | 是(本质) | soy | eres | es | somos | sois | son | | estar | 是(状态) | estoy | estás | está | estamos | estáis | están | | tener | 有 | tengo | tienes | tiene | tenemos | tenéis | tienen | | hacer | 做 | hago | haces | hace | hacemos | hacéis | hacen | | ir | 去 | voy | vas | va | vamos | vais | van | | poder | 能 | puedo | puedes | puede | podemos | podéis | pueden |

ser 和 estar 都是"是",区别要专门花一晚搞清楚: ser 用于本质属性 (国籍、职业、性格), estar 用于状态 (位置、心情、暂时状态)。"我是中国人"用 ser,"我在北京"用 estar。

第一阶段把这 6 个动词背到张口就来,第二阶段才学得动。

第二阶段: 500 词 + 简单句型

第 31 到 70 天,40 天,目标把词汇从 100 扩到 500。

我的做法是: 每天新学 10 个词,复习昨天和前天的 20 个。10 + 20 = 30 个词,15 分钟搞定。剩下 10 分钟造句。

造句的句型只用三种:

1. Yo + 动词 + 名词: Yo tengo un perro. (我有一只狗)
2. Sujeto + ser/estar + adjetivo: Madrid es bonito. (马德里很美)
3. Yo quiero + infinitivo: Yo quiero comer. (我想吃)

这三种句型够撑起所有 A1 到 A2 的日常表达。复杂的从句、虚拟式、过去时全部 100 天后再说。

第三阶段: 听力浸泡 + 真实场景

最后 30 天,词汇够了、动词够了,缺的是耳朵和嘴。

听力

我每天通勤 30 分钟听一档叫 "Notes in Spanish" 的播客 (Beginner 系列),不强求听懂每个词,听整体语流。

YouTube 上有个频道叫 "Dreaming Spanish",纯西语视频带画面,适合零基础。

口语

我用一个叫 Tandem 的 app 找语伴,每周和一个西班牙人语音 20 分钟,他教我西语我教他中文。

如果你不想跟陌生人聊天,对着 ChatGPT 用语音模式,假设它是马德里服务员,你练点菜流程。

100 天结束后,我去了马德里

下飞机第一个测试是机场出租。司机问我"De dónde eres?" (你来自哪里),我答"Soy de China, de Beijing" (我来自中国北京)。他听懂了,我也听懂了他后面问的"primera vez en España?" (第一次来西班牙吗)。那一刻 100 天的投入有了回报。

实际场景里听力比口语难得多。当地人语速是教材的 2 倍,而且吞音严重。前 3 天我基本只能在餐厅指菜单,第 4 天开始能跟服务员讲完整句子。

想学其他语言怎么办

同样的方法可以套用到法语、意大利语、英语。我自己也在学法语,用 french-vocab-100 走同样的 100 词路径。

如果你的孩子在学意大利语 (北京有家长群在搞兴趣班),italian-vocab-100 也可以参考。

英语水平想自测,english-vocab-quiz 用 20 道题给你大致定一个 CEFR 等级,5 分钟跑完,知道自己处于 A2 还是 B1 心里有谱。

一句话总结

100 天学到 A2,关键不是天赋,是节奏。每天 15 分钟比每周末刷 3 小时有用 10 倍。

spanish-vocab-100 给你第一阶段的底座,剩下的靠坚持。

Made by Toolora · Updated 2026-05-26

我 2022 年签房贷合同那天,银行经理花了 90 秒把两个选项口头讲完,然后递笔过来。我当时其实没听懂,签完回家自己用 Excel 跑了三天,才搞明白两种方式 30 年下来差了 12 万利息。

这篇用一组真实的数字 (100 万本金 / 30 年 / 4.0% 年利率) 把两种还款方式从公式到月供再到总利息全部跑一遍,以及一个我后来总结的提前还款判断方法。

先看结论

| | 等额本息 | 等额本金 | |---|---|---| | 首月月供 | 4,774 元 | 6,111 元 | | 末月月供 | 4,774 元 | 2,787 元 | | 30 年总利息 | 718,696 元 | 601,667 元 | | 利息差 | | 省 117,029 元 |

等额本金 30 年下来比等额本息少还约 11.7 万利息,但前 10 年的月供压力大很多。要不要选它,看你的现金流。

下面拆数学。

等额本息的公式

每月还相同的钱,前期还的大部分是利息,后期才是本金。月供公式:

M = P × r × (1+r)^n / ((1+r)^n - 1)

• P = 贷款本金 (1,000,000)
• r = 月利率 (年利率 / 12 = 0.04 / 12 ≈ 0.003333)
• n = 还款月数 (30 × 12 = 360)

代入算: M ≈ 4,774.15 元

每个月固定这个数,360 个月不变。总还款 = 4,774.15 × 360 ≈ 1,718,696 元,其中利息 718,696 元。

第一个月的利息占比:

首月利息 = 1,000,000 × 0.003333 ≈ 3,333 元
首月本金 = 4,774 - 3,333 = 1,441 元

也就是说,你第一个月还的 4,774 块里,3,333 是利息,只有 1,441 是真正还了本金。这就是为什么前几年觉得"还了那么多怎么本金没动"。

等额本金的公式

每月还相同的本金,加上当月剩余本金产生的利息。月供公式:

本月本金 = P / n = 1,000,000 / 360 ≈ 2,778 元 (固定)
本月利息 = 剩余本金 × r
本月月供 = 本金 + 利息

第一个月:

本金: 2,778
利息: 1,000,000 × 0.003333 ≈ 3,333
月供: 6,111 元

最后一个月:

本金: 2,778
利息: 2,778 × 0.003333 ≈ 9
月供: 2,787 元

总利息 = 等差数列求和 ≈ 601,667 元。

为什么等额本金省 11.7 万

本质是: 等额本金前期还了更多的本金,后期需要付利息的本金基数小了。

我用一个粗暴的类比: 假设你借朋友 1000 块,日息千分之一。

• 方案 A: 每天还 11 块,30 天还完
• 方案 B: 第一天还 200,后面 800 慢慢还

方案 B 后面 29 天的利息是基于 800 算的,方案 A 后面 29 天的利息是基于近 1000 算的。利息差就出来了。

具体的逐月对比,我会直接打开 mortgage-calculator 输入这三个参数,它会出 360 行的明细表,每行写清本金、利息、剩余本金。比 Excel 自己写公式快多了。

怎么选

我建议按这三个问题判断:

1. 现在月入多少?

如果首月月供占月入超过 50%,选等额本息。生活要紧。

100w / 30 年 / 4.0%,首月 6,111 元,意味着如果你税后月入低于 12,000 元就不要选等额本金。

2. 未来 5 年现金流稳定吗?

如果你正在创业、行业波动大、有娃要养,选等额本息。固定月供给你心理安全感。

3. 有没有提前还款的可能?

如果你大概率 5 到 10 年内会提前还,选等额本息和等额本金差距会缩小。具体多少差,可以用 loan-comparison 把两种方式并列对比,假设第 7 年提前还 30 万,看哪种最终利息更低。

关于提前还款

我自己 2023 年中提前还过 20 万,那年我用 loan-prepayment-calculator 算了三种方案:

| 方案 | 描述 | 节省利息 | |---|---|---| | 缩短年限 | 月供不变,30 年变 23 年 | 约 19 万 | | 减少月供 | 年限不变,月供降低 | 约 11 万 | | 不还,投理财 | 假设理财年化 4.5% | 多赚约 1.6 万 |

结论很清晰: 缩短年限最划算,前提是你后面 23 年的月供你扛得住。

什么时候提前还划算的判断,网上有个口诀叫"前期还划算,后期还鸡肋",其实就是: 还款年限过半之后,你每个月还的大部分已经是本金,利息没多少了,提前还的边际收益变小。

具体到一个数字: 30 年贷款,第 15 年是分界线。第 15 年之前提前还,省的利息明显;第 15 年之后,你不如把钱拿去 compound-interest-calculator 算一下,投个稳健理财可能更划算。

一句话总结

房贷本质就是借钱付利息。两个公式不复杂,真正难的是看清自己的现金流。

mortgage-calculator 把数字跑出来,你才有谈判和决策的底气。签字之前花 10 分钟跑一遍,可能就省下一辆车。

Made by Toolora · Updated 2026-05-26

我的浏览器书签栏里有一栏叫 "tools", 装的就是这 30 个东西。多数是十秒钟用完就关掉的: 把一段 JSON 美化一下、查个 HTTP 状态码、把字符串 base64 一下。装本地 CLI 太重, 在 VS Code 里翻插件太慢, 这种活就该在标签页里完成。

下面这份清单按我自己的使用频次和场景分组。每个工具都开过, 不会出现"作者也没用过的工具混进来凑数"的情况。所有页面都是纯前端, 你粘进去的数据不会出这个标签页。

1. JSON / YAML / 配置文件 (5 款)

1. JSON 格式化器

我打开次数最多的一个标签页, 没有之一。接联调环境时, 后端塞过来的 JSON 经常是单行 12 KB, 这页打开能立刻美化、折叠、按路径检索。5 MB 以内都是秒开, 不会像某些在线 JSON 工具拖一下卡两秒。我把它钉在了任务栏的第一个固定标签里。

2. YAML 格式化器

写 K8s manifest 和 GitHub Actions workflow 时, 缩进错一格就报错。这个工具能高亮非法缩进, 顺便告诉你某个 key 重复了。比直接交给 kubectl apply 再看错误日志, 快两倍。

3. YAML 转 JSON

拿到一份 docker-compose.yml 想塞给一个只吃 JSON 的工具时, 直接粘进去出结果。反向需求也常见, 写 helm values 时我有时候先用 JSON 思考结构再转 YAML。

4. CSV 转 JSON

运营给我一份 CSV 让我导入数据库, 中间这一步永远是 CSV → JSON → SQL 批量 insert 语句。表头自动当 key, 空字段不会丢, 双引号转义也处理得对。

5. XML 转 JSON

对接老系统时 XML 还是绕不开的, SOAP 和 RSS 都在用。粘一段 XML 进去, 能看到树状结构再决定怎么解析。

2. 速查表 (8 款)

6. Git 速查表

git reset --hard 和 git reset --soft 的区别每隔三个月就要查一次。比开浏览器搜 stackoverflow 然后被广告糊一脸, 不如直接来这里。包含 rebase / cherry-pick / reflog 的几个常用救命姿势。

7. Vim 速查表

本地有 cheat.sh 是好, 但远程登 SSH 跳板机时, 用浏览器查一下 :%s/foo/bar/gc 的语法是最快的。命令按编辑/移动/搜索分类, 一屏看完。

8. Bash 速查表

写 shell 脚本时, ${var%.*} 和 ${var%%.*} 到底哪个去掉的多, 我每次都得验证。这页把变量展开、参数替换、循环结构、test 表达式分块罗列, 翻三秒就能确认。

9. Docker 速查表

docker exec 和 docker run 的参数顺序经常打错, 容器进不去时排错也常翻 --mount 和 -v 的语义差别。这页把日常 80% 命令分了 build / run / 网络 / volume 四块。

10. Kubectl 速查表

debug 一个 pod 时常要的几个魔法咒语: kubectl get pod -o wide、kubectl describe、kubectl logs --tail=100 -f、port-forward 的参数顺序。打印出来贴显示器边上的那种内容, 这页直接装下了。

11. SQL 速查表

不写 SQL 的项目期, JOIN 类型一过半年就糊了。INNER / LEFT / FULL OUTER 的图示放在一起, 加上 window function 那几个最常用的 ROW_NUMBER / RANK / LAG, 写复杂查询前先翻一下省得返工。

12. Regex 速查表

正则表达式那几个零宽断言 (?=) (?<=) (?!) (?<!) 我能记住语义记不住符号。这页按断言、量词、字符类、捕获组分块, 写复杂正则前两秒钟回血。

13. Tailwind 速查表

写 Tailwind 时, space-x 和 gap 的区别、grid-cols-[200px_1fr] 这种任意值写法, 不查表写不出来。这页按布局、间距、文字、颜色、响应式分组, 找一个 class 不会被淹没在官方文档的瀑布里。

3. 加密 / 哈希 / 编码 (4 款)

14. Base64 编解码

HTTP basic auth 写测试用例时, 把 user:pass base64 一下塞 Authorization header。在 nginx 配 auth_basic_user_file 时也会用到。比开终端 echo -n "user:pass" | base64 还快一点, 因为不用怕忘记 -n。

15. JWT 解码器

生产环境 401 时, 把请求头里那串 token 粘进来看 payload 里的 exp 是不是过期了, 看 iss 是不是发错了。完全本地解析, 这点很重要, 生产 token 这种东西不能往不知名的在线工具上送。

16. JWT 编码器

写测试时手搓一个 JWT, 选算法、填 payload、给 secret, 一秒出。常用来跑 e2e 测试时模拟不同角色的用户。

17. MD5 / SHA 哈希计算器

对比文件完整性、生成签名比对、把字符串哈希后当 key 用。MD5/SHA-1/SHA-256/SHA-512 一起出, 不用切工具。

4. DevOps / 运维 (5 款)

18. Cron 表达式解释器

写 0 */6 * * 1-5 时, 我每次都要确认它真的是工作日每 6 小时执行而不是周末。这页粘进去后给出"未来 5 次执行时间", 比心算靠谱。

19. Crontab 助手

按下拉框选"每天 9 点"、"每周一三五凌晨 2 点", 自动生成 cron 表达式。给不熟悉 cron 的同事临时拼一条很顺手。

20. HTTP 状态码查询

418 是什么、307 和 308 差在哪、426 怎么触发。按数字搜或按场景搜都行, 比 MDN 翻一遍快。

21. DNS 记录类型解释器

SPF / DKIM / DMARC 三件套配邮件域名时, TXT 记录里到底该写什么。CAA 记录限制证书签发的语法。这页按记录类型一个个讲, 配实际例子。

22. Linux 权限计算器

755 和 644 我背得下来, 但 1777 (sticky bit) 和 4755 (setuid) 偶尔要排错。勾选框点一下就能拿到数字, 反过来粘个数字也能解析。

5. 文本 / 数据处理 (4 款)

23. 文本去重

日志里捞出 1000 行 IP 想去重时, 这页比写 sort | uniq 还省事, 主要是它顺带告诉你原本多少行、去重后多少行、重复率多少。

24. 文本排序

按字母、按数字、按长度排; 升序降序; 反转。整理 import 语句、整理 SQL IN 列表、整理环境变量, 都在这页搞定。

25. 文本差异对比

本地没装 diff 工具时, 或者要对比的两段文本是聊天里粘过来的, 浏览器里红绿对比一下就行。行级和字符级两种粒度都支持。

26. UUID 生成器

写测试数据、初始化数据库主键、给 trace ID 填值。一次生成 1-100 个, 复制按钮一键全选。v4 是默认, v1/v7 也支持。

6. 颜色 / 设计 (4 款)

27. 颜色选择器

写 CSS 时不开 Photoshop 也能选色, HEX / RGB / HSL 三种格式同步切换。给图片用还得配合下一个工具。

28. 图片取色

设计师丢个截图过来让"按这个色调", 上传图片直接抽出 5-10 个主色, HEX 一键复制。比手动用 PS 的吸管挨个戳省事。

29. CSS 渐变生成器

linear-gradient 三个色标我能写, 但 conic-gradient 一上手就要查。这页拖滑块可视化调, 实时预览, 复制 CSS 直接粘进去。

30. 对比度检查器

WCAG AA 要求正文 4.5:1, AAA 要求 7:1。设计稿丢过来的浅灰文字一上线就被无障碍工具喷, 上线前先拿这页校一下。

怎么用最高效

我自己常用的三种组合姿势:

1. 联调流: JSON 格式化 + JWT 解码 + HTTP 状态码 三个标签页常驻。后端给的接口不对劲时, 30 秒内能定位是协议错了、token 错了还是数据结构错了。
2. 运维流: Cron 解释器 + Crontab 助手 + Linux 权限计算器。配定时任务前先在浏览器里把表达式算对、把权限位算对, 提交脚本时不至于第二天凌晨被报警吵醒。
3. 设计流: 颜色选择器 + 图片取色 + 对比度检查器。前端写完一个组件后, 把截图放进去抽主色, 再把主色对背景跑一遍对比度, 不会等 PR review 时被设计师打回。

书签栏腾一栏出来, 把这 30 个钉进去, 你会发现一年之中省下来的搜索时间够你看完几本书。

Made by Toolora · Updated 2026-05-26

我 2024 年初 70 公斤,1.75 米,体脂率 22% 左右。那时候我穿衣服明显有小肚子,跑 3 公里就喘。当年 6 月体检看到尿酸偏高,医生说"年纪上来了要注意体重"。

90 天后我减到 65 公斤,体脂 16%。腰围从 86 厘米降到 80 厘米,跑 5 公里不喘。

这篇拆我的方法。没有秘方,本质就是卡路里赤字 + 力量训练。重点是数学要算对,不能凭感觉。

卡路里赤字的本质 - 一个减法

人体重的变化遵守能量守恒:

能量摄入 < 能量消耗 → 体重下降
能量摄入 > 能量消耗 → 体重上升
能量摄入 = 能量消耗 → 体重不变

"卡路里赤字" 就是上面第一条,摄入比消耗少。1 公斤脂肪大约 7700 千卡,所以理论上:

每天赤字 500 千卡 × 14 天 = 7000 千卡 ≈ 减 0.9 公斤

实际会比理论略少 (身体会适应、肌肉也可能掉一点),但量级对的。

第一步: 算你的 TDEE

TDEE 是 Total Daily Energy Expenditure,你一天总共消耗多少千卡。

公式两步:

1. 算 BMR (基础代谢率)

身体不动一天烧多少卡。Mifflin-St Jeor 公式:

男性:

BMR = 10 × 体重(kg) + 6.25 × 身高(cm) - 5 × 年龄 + 5

女性:

BMR = 10 × 体重(kg) + 6.25 × 身高(cm) - 5 × 年龄 - 161

我 35 岁 70kg 175cm 男:

BMR = 10×70 + 6.25×175 - 5×35 + 5
    = 700 + 1094 - 175 + 5
    = 1624 千卡

不想手算的就直接用 bmr-calculator,输入身高体重年龄性别,1 秒出结果。

2. 乘活动系数得 TDEE

| 活动强度 | 描述 | 系数 | |---|---|---| | 久坐 | 全天办公,几乎不动 | 1.2 | | 轻度 | 每周 1 到 3 次轻量运动 | 1.375 | | 中度 | 每周 3 到 5 次中等强度 | 1.55 | | 高强度 | 每周 6 到 7 次高强度 | 1.725 | | 极高 | 体力工作 + 每天训练 | 1.9 |

我属于"中度",每周跑 3 次步 + 2 次力量:

TDEE = 1624 × 1.55 ≈ 2517 千卡

也就是说,我每天吃 2517 千卡体重不变。

calorie-calculator 把这两步合在一起,直接出 TDEE 和不同减重速度对应的目标摄入。

第二步: 定赤字大小

这是最关键的一步,大部分人犯错的地方是赤字定太大。

安全赤字: 占 TDEE 的 15% 到 25%

我 TDEE 2517,赤字定 500:

目标摄入 = 2517 - 500 = 2017 千卡
预期减重 = 500 × 7 / 7700 ≈ 0.45 kg/周

每周减 0.5 公斤,90 天大概减 6 到 7 公斤。这是可持续的速度。

为什么不能赤字 1000+

我刚开始也想"赤字 1000,2 周减 2 公斤多爽",但实际尝试一周就崩了。原因:

1. 饥饿感不可控: TDEE 60% 以下的摄入会触发强烈饥饿,坚持不过 1 个月
2. 代谢下调: 身体感觉到饥荒会主动降低 BMR,减重停滞
3. 肌肉流失: 没有足够蛋白质和能量,身体会拆肌肉换能量
4. 复胖率高: 短时间剧烈减重,反弹率 90% 以上

国际通行的建议: 每周减重不超过当前体重的 1%。70kg 的人就是每周最多 0.7kg。

第三步: 蛋白质要够

减脂期蛋白质摄入要拉到每公斤体重 1.6 到 2.2 克。我 70kg,每天蛋白质 130 克左右。

为什么? 因为赤字状态下身体会拆肌肉,蛋白质够才能保护肌肉,让"减掉的那 5kg"全是脂肪而不是肌肉。

130 克蛋白质大概是:

• 早餐: 2 个鸡蛋 + 1 杯牛奶 = 20g
• 午餐: 鸡胸 150g = 35g
• 晚餐: 三文鱼 120g = 25g
• 加餐: 蛋白粉 30g + 希腊酸奶 = 35g + 15g

凑得到。

我 90 天的实测数据

我每天用 weight-loss-tracker 早晨空腹称重,记录体重曲线。

| 周次 | 起始体重 | 末周体重 | 减重 | 备注 | |---|---|---|---|---| | 1 到 4 周 | 70.0 | 68.2 | -1.8 | 第一周-1.2 多是水,后面稳定 | | 5 到 8 周 | 68.2 | 66.8 | -1.4 | 平台期一次,5 天没动 | | 9 到 12 周 | 66.8 | 65.0 | -1.8 | 加了 16:8 间歇饮食 | | 总计 | 70.0 | 65.0 | -5.0 | 90 天 |

注意第二段 5 到 8 周,有一次 5 天体重不变。这就是减脂平台期,正常现象,不要急着加大赤字。坚持原来的节奏,1 周后又开始掉。

几个坑提前告诉你

1. 不要每天称体重然后焦虑。一天里体重浮动 1 到 2 公斤是水分变化,完全正常。看 7 天移动平均才有意义
2. 来例假/啤酒之夜后第二天体重多 1.5 公斤。是水钠潴留,2 到 3 天会回去
3. 第一周减得快不是减脂,是糖原储水。糖原每克带 3 克水,你少吃几天碳水水分先掉
4. 不要全用有氧。光跑步不练力量,减下来的体重 1/3 是肌肉,身材会显得松垮。每周 2 次力量训练是底线

间歇饮食加分项

我后 30 天加了 16:8 间歇饮食 (每天 8 小时内吃完,16 小时空腹)。不是因为它能多减脂,而是它自然降低了我的进食量。中午 12 点到晚上 8 点之间吃,2 顿正餐基本就到 2000 千卡上限。

如果你想试 16:8,intermittent-fasting-tracker 帮你记录每天的进食窗口,看坚持情况。我自己用了一个月觉得对睡眠和精神状态都有提升,现在变成日常。

一句话总结

减肥没有秘方。算清 TDEE,定 15% 到 25% 的赤字,坚持 12 周,体重就会动。

weight-loss-tracker 每天 30 秒记录,90 天回头看曲线,你会感谢现在开始的自己。

Made by Toolora · Updated 2026-05-26

Toolora 是一个常用工具的合集,目前 74 个,后面会再长。JSON 格式化、图片压缩、取色器、各种计算器 —— 全部在你这个浏览器标签页里跑。不要邮箱、不要注册、没有"免费版 vs Pro"那道墙。你看到什么就是全部。

我做这个站起因很简单: 我自己每天都被那些塞满广告、强制登录的工具页浪费时间。我也不太放心把生产环境的 JSON 粘进一个不知道幕后是什么的网站。于是干脆自己写一个我自己想用的版本: 每个工具 Lighthouse 必须 95+,每个工具的 JS 预算约 30 KB,你用任何一个工具时打开开发者工具的 Network 面板,应该是空的。不用相信我,你自己看。

下面是我们后台里反复出现的五类用户,以及我会推荐每类用户先收藏的 3 个工具。

1. 学生

写作业、写复盘、写公众号草稿、做研究笔记。

• Markdown 表格生成器 — 写月度复盘、读书笔记时,把对比表格做出来比纯文字直观 10 倍。
• 字数统计 — 作文 800 字、论文摘要 300 字、知乎回答 500 字 —— 实时看到字数,不用提交后才发现超了。
• 图片压缩 — 班级群、学校系统经常限制 2MB,4MB 截图压到 500KB 内毫无压力。

2. 家长

辅导孩子、家庭账本、给爸妈拍的照片。

• 中文拼音转换器 — 给孩子辅导生字时打一段拼音对照表,比手写快得多;给老人传文档时也用得上。
• 图片裁剪 — 把孩子获奖照片裁成证件照规格、把家庭照剪成微信表情或朋友圈封面。
• 二维码生成器 — 家长群临时收 WiFi、收个人微信、收作业链接,一个二维码省得在群里贴长链接。

3. 开发者

那种"一周用 12 次但永远懒得装 VS Code 插件"的小工具。

• JSON 格式化 — 美化、压缩、校验。5MB 的接口返回打开也是一秒内。
• 正则测试 — 实时高亮匹配、看分组。比在终端 grep -E 试错舒服多了。
• JWT 解码 — 粘贴 token 看 header 和 payload,完全本地解析。生产 token 这种敏感东西,不会想发出去到一个不知道的服务器。

4. 内容创作者

短视频封面、跨平台发文、社交分发。

• 图片尺寸调整 — 一张原图同时导出 1080×1080(小红书)、1920×1080(B站封面)、1080×1920(抖音竖图),不用打开 PS。
• 配色生成器 — 取色、转换 HEX/RGB/HSL,确保设计稿和最终发布颜色一致。
• Markdown 转 HTML — 公众号、知乎、个人博客之间倒腾文章再也不用手动改格式。

5. 普通办公

不写代码,但每天用电脑做大量琐事。

• PDF 转图片 — 把 40 页 PDF 里的某一页单独导成 PNG,贴到 PPT、贴到微信都直接能用,而且 PDF 不会被传到任何服务器。
• 房贷计算器 — 等额本息 vs 等额本金,不同利率、不同年限算一遍再决定要不要签合同。比 Excel 拉表快。
• 单位换算 — 米/英尺、公斤/磅、摄氏度/华氏度,精度够给正式发票用。

怎么用得更顺手

两个习惯就够了:

1. 把 toolora.info 加书签。独立工具站的全部价值就在于 —— 你不再需要去 Google "JSON 格式化在线" 然后从 5 个广告页里挑一个不那么烂的。一个书签替掉十次搜索。
2. 发现哪里不对就给我发邮件。 lilei961112@gmail.com,真人邮箱,我本人看。bug、漏的功能、"这个数算的跟 Excel 对不上",欢迎都发。

就这些。如果你看到这里,你身边大概率有人正抱怨你今天替掉的那个工具站,把链接发给 ta。

Made by Toolora · Updated 2026-05-25