健康维C看到一串 DDDDDDDDDDDDDDD 的时候，我第一反应不是恶作剧，也不是手抖。作为一个经常在需求文档、原型图、命令行参数和代码注释里跟各种符号打交道的人，这种情况我见过太多次了。很多人会随手用一串重复字母来占位，或者用它表达“就这么个意思”，等到真正做方案、做接口、做排查的时候，才发现大家都被这串没有明确含义的字符搞晕了。
这篇博文就想从这串“DDDDDDD”出发，聊聊我实际工作里和“D”相关的那点事：占位符到底该怎么用才不会坑人、命令行里各种 -d 参数怎么区分、技术圈里大写 D 开头的缩写有多容易产生歧义，以及当代码和数据库里真的混进一长串重复字母时，应该用什么样的排查思路去收场。如果你是刚入行的开发、产品、运维，或者经常需要写文档、跑命令、翻日志的人，这篇内容应该能帮你省下不少踩坑时间。
1. 占位符的使命与边界：一串重复字母为什么会出现在正式内容里
先别急着笑话这串 D。占位符这个东西，几乎每个行业都在用：UI 设计稿里用 Lorem ipsum 代替正文，接口文档里用 xxx 或 <待补充> 表示字段，代码里用 foo、bar、tmp 占变量名，甚至键盘乱敲出来的 ddddd 也会被人粘贴到配置文件的注释里。它本质上是沟通成本最低的临时对象，但也是最容易被忽略的交接隐患。
1.1 占位符的真实角色
占位符解决的问题很直接：在信息还不完整的时候，先把结构搭出来。比如设计一个表格，字段名还没定，你不可能干等；你先填 field1、field2，或者干脆 aaaaa、ddddd，让上下游继续推进。再比如写 SQL 脚本，某个过滤条件的具体值还没确认，你随手写个 'DDDD'，本来打算回头改，结果一忙起来就忘了。
从我自己的经验看，占位符真正危险的地方不是它“临时”，而是它“看着像真的”。一串 DDDDDDDDDDDDDDD 如果出现在日志里，搜索时你都不知道该用什么关键词去匹配；如果出现在界面上，用户会以为这是产品文案；如果进了接口返回值，前端可能原样渲染出去。占位符的边界就在于：它必须被限定在“暂时无人在意的过渡区域”，一旦进入正式数据的流通链路，就必须被替换掉。
1.2 占位符与空值的边界
有一个不少新人搞混的概念：占位符和空值不是一回事。null、None、空字符串 "" 是明确表示“这里没有数据”，有固定的判定逻辑；而占位符 DDDDD 是一段“临时假装这里有数据”的值。在很多地方，占位符会被当成真实数据参与运算。
举个实际例子：一个对象初始化时写了 name: "DDDDD"，后续逻辑会做 if name == "DDDDD" 这样的判断。表面看没什么问题，但一旦有人把其中一个地方的占位符改成了 DDDD，或者数据库里存的是 ddddd（大小写不一致），判断就失效了。更麻烦的是，占位符可能进入统计报表、发送到外部系统，甚至被用户截图投诉。所以我在团队里一直强调一个原则：占位符只能出现在过渡层，不能出现在持久层和展示层。
1.3 占位符使用底线
基于这些年踩过的坑，我给自己定了三条占位符使用底线：
- 能表达意图，就不要纯乱码。
TODO: 此处待确认比