卖的时候就没收的钱在会计上就不存在，商品进价 500 ，用银行存款买，推荐零售价 1500 ，实际以 1000 售出，收的现金，那么会计分录是这样的（先忽略税的问题）：


借 库存商品 500
贷 银行存款 500


借 主营业务成本 500
贷 库存商品 500

借 库存现金 1000
贷 主营业务收入 1000


如果退款，当然是反向。

不谈物理，我想到了上古时代（可能是我做梦梦见的）如果把 DirectX 区域用 Print Screen 截图再粘贴到画图里，可能会导致粘贴的部分是动态的，被 DirectX 渲染而且随着控制 DirectX 渲染的软件画不同的内容，画图里已经粘贴的（理论上我们认为是静态的）图会跟着变化。 🤣

另外为本地账户关联微软账户的方法有两种：一是在设置应用里管理本地账户时选择“使用 Microsoft 账户登录”，这是明显的；另一种是登录 Microsoft 账户 SSO 的时候 Windows 推荐你使用微软账户登录，这是不明显的，随意点过去就会关联。

@gitignore #10 关联微软账户的本地账户只有第一次登录需要联网（我不太记得在未关联的账户里关联之后是否算做已经登录过，但我的想像中应该算的），之后断网的时候可以用最后一次本地知道的密码登录。你看到欢迎屏幕持续转圈可能是已经登录成功但是 explorer 在准备。此时要检查是否登录成功，可以反复按 Ctrl+Alt+Del ，如果出现“Windows 安全”对话框（其中的选项包括锁定、切换用户、打开任务管理器之类的），则说明已经登录成功，在等 shell 准备，否则就是没有登录成功。

这个问题很好，下面是我的想法。

1. 异侧还是同侧？

别人发的、自己发的分别在两侧似乎仅适合窄界面（例如手机）。Windows 上的 Telegram 会根据宽度决定布局——如果聊天面板不够宽，则自己发的显示在异侧，否则显示在同侧。

2. 为什么要异侧？

异侧显示可以增加“发件人是谁”的视觉提示。窗口窄的时候异侧显示不会带来“行定位”的困难。

3. 为什么不异侧？

窗口太宽的时候，异侧显示在连续阅读历史时眼睛很累——需要不断切换方向，并且太宽的时候“找异侧的下一行”很困难。

4. 为什么其他人发的在左侧，自己发的在右侧？

这和文本的渲染方向有关系，中文、英文横排是从左到右书写，用户最需要的是阅读他人发来的消息（因为用户通常还记得自己发的消息是什么），设计上应该降低这件事情的难度，他人发来的消息的开头永远在窗口左边（阅读时一行开头的位置），非常容易定位——相比之下，用户自己发的消息的开头处于窗口中间，而且具体是中间的哪里和消息长度有关，定位起来稍微费力一些。

此外，“发送”按钮也在右侧，如果有发送动画，那么输入消息的文本框会移动到消息历史里的位置，此时移动到左边不如移动到右边（刚刚点击的按钮所在的位置）自然——即“局部性”（对右边进行了操作，自然希望效果出现在右边）。

阿拉伯文、希伯来文等横排从右到左书写的语言里，自己发的消息会显示在左边，其他人发来的消息会显示在右边。因为这些文本的用户每行是从右边开始阅读。

很有上古时期 Flash 做的模拟 UI 的内味儿

目前的实现是必须消耗能量的，因为计算过程不可逆，会擦除系统中的信息，根据 https://en.wikipedia.org/wiki/Landauer's_principle 这需要能量（会放热，即转换为内能）。

能量除了热损耗（变成内能）还可以暂时储存在元器件里面。

因为 C 的缘故，void foo(char x[10]) 和 void foo(char *x) 是一个意思。要传递数组引用而不是指针的话，应该 void foo(char (&x)[10])。

不太确定 OP 在期待什么。公司的电脑是公司控制的，公司可以不间断查看你的内存，那么 Chrome 记录不记录也没什么区别，你能做的就是不使用公司电脑做不能让公司知道的事情。

>反贼回复的指令和丞相的相反

这样的反贼过于友好了。

>如果进攻指令数过半数，就会进攻

这并不是惟一的策略。

您描述的并不是 Byzantine 将军问题，Byzantine 将军问题的设定是：

1. 反贼和其他人通信的时候可以 **任意使坏**，比如和一个人说进攻，和另一个人说撤退；
2. 忠臣最终需要统一决策，不能一个忠臣进攻，另一个撤退；
3. 如果将军是忠诚的，那么忠臣的决策和将军一致。

只会说反话的反贼是很弱的。

@julyclyde #34 CR 的作用是“回车”，也就是把光标移动到行开头，在 CR 之后继续打印，自然会踩踏先前的内容。理同 ab BKSP cd 看起来是 acd 一样。

@julyclyde #14 然而你的这个想法和 #3 体现的想法是矛盾的，如果你认为 curl 应该“按文本”输出，那也和 GitHub Web API 输出的是 CRLF 还是 LF 没有关系，因为此时你认为的 curl 的行为会让用户无法感知 HTTP 传输的到底是 CRLF 还是 LF 。

@julyclyde #11 是你对 shell 的期待有误，Unix 风格 shell 的管道完全是二进制的，任何对数据的解读都是程序完成。

Re: “OP 的假设就被推翻了呢”
为什么你会觉得 OP 的假设是自然的？那明明是《我比 GitHub 做 Web API 的员工更懂 HTTP 之口嗨 Windows 用户真时髦》最新一期。

@julyclyde #3 curl 不参与编码解析，自然是 HTTP 给什么就返回什么，否则（若是 curl 参与编码解析的话）你把 curl 传入管道的时候会出现非常糟糕的状况。

@NoOneNoBody #14 您没有理解 PowerShell 的类型系统和传参逻辑，$PSScriptRoot 和 "$PSScriptRoot" 是完全一样的，下面两条命令只有运行效率的区别，没有效果的区别：

cd $PSScriptRoot
cd "$PSScriptRoot"

如果当前脚本的完整路径是 C:\Path with Space\My Script.ps1 ，那么 $PSScriptRoot 是一个字符串，长度是 18 ，内容是 C:\Path with Space ，你写

cd $PSScriptRoot
cd 'C:\Path with Space'
cd "C:\Path with Space"

三句话的效果完全一样，而且和

cd C:\Path with Space

效果不一样，因为后者会被理解为想要传入三个参数，分别是 'C:\Path' 和 'with' 和 'Space'。

而你写的

$var = Split-Path -Parent $MyInvocation.MyCommand.Definition

之后

cd "$var"

和 cd $var 的效果是完全一样的，因为 $var 已经是字符串了，此外 cd "$var" 依然有通配符的问题，正确的写法是 cd -LiteralPath $var 。

@mylovesaber #1 不太确定您的结论是如何来的，但是据我所知使用 CR LF 标记大多数行结尾是 HTTP 规定的，而且是自古以来。

@tyx1703 #38 yan 是 ian 为了方便切分音节的写法而已，拼音字母 y 的使用规则是：音节开头的 i 、ü 改写为 y 、yu 。

iê（拼音规则是 ie ）和 iên （拼音规则是 ian ）的区别在于是否是鼻韵，也就是叶、烟的区别。