Null SafetyがFlutter2.0で正式に導入になったようですね。
Null Safetyのintroduction（導入）について、公式Youtubeで説明されているので、文字起こしと簡単な日本語訳を以下に記載しておきます（間違っている箇所があればご指摘いただけたらと思います。）。
deepL使ってます。
動画と合わせて御覧ください。
英語が苦手な方が公式Youtubeをざっくり理解する手助けになれば幸いです。
Null Safety in Dart -Introduction
Generally, variables hold some kind of a value.
An integer can be 42, or 0, or minus 1.
A string can be "hello world!" or "what?"
一般的に、変数は何らかの値を保持します。
整数には42、0、マイナス1などがあります。
文字列には "hello world!" や "what?" などがあります。
But most programming languages, including Dart, also have the notion of a null value, no value.
For example, it makes sense for a favorite color variable to be null.
Some people just don't have a favorite color.
しかし、Dartを含むほとんどのプログラミング言語では、null値、つまり値がないという概念も持っています。
例えば、好きな色の変数がnull値になるのは理にかなっています。
好きな色が単にない人もいるのです。
This creates a problem, though.
If variables can be of a certain type, like integer or color, or null, then you must think, every time you use it, is this color a color or is it null?
Is this value in this list of integers an integer, or is it null?
Experience shows that it's hard to think about this all the time, and that developers tend to introduce null errors quite often.
And null errors are bad, because they can crash your app, which is something that users don't appreciate.
しかし、これには問題があります。
変数が整数や色、あるいはnullのような特定の型を持つことができる場合、それを使用するたびに、この色は色なのか、それともnullなのかを考えなければなりません。
この整数のリストの中のこの値は整数なのか、それともnullなのか？
経験上、このようなことを常に考えることは難しく、開発者はかなり頻繁にnullエラーを導入する傾向があることがわかります。
そして、nullエラーはアプリをクラッシュさせる可能性があるので、ユーザーは好ましく思っていません。
Enter null safety.
By default, Dart now assumes that your variables are never null.
For example, the age variable here is not non-nullable.
It must never be assigned null.
That's almost like a double negative, so let me put it another way.
null safetyに入門しましょう。
デフォルト（初期設定）では、Dartは変数が決してnullではないと仮定するようになりました。
例えば、ここでの age 変数はnullではありません。
これは決してnullを代入してはいけません。
これはほとんど二重否定のようなものなの(「nullではない」→「値が入っていない状態ではない」という表現を指すのだと思われます)で、別の言い方をしてみましょう。
The age variable must always be some number.
It can't be null.
This is the default. Types are non-nullable by default.
You can still use null for variables, but you have to be explicit about it.
Here we are saying that favoriteColor is nullable by adding the question mark.
The variable can be null.
It can be a color or null.
age変数は常に何らかの数値でなければなりません。
nullにすることはできません。
これがデフォルトです。型はデフォルトではnullにできません。
変数にnullを使うことは（とはいえ）可能ですが、(その場合には、)明示的に指定する必要があります。
ここでは、favoriteColorにクエスチョンマークを付けて、nullableであることを示しています。
変数はnullにすることができます。
色を指定してもいいし、nullを指定してもいいのです。
Because we're explicit, Dart can now help us avoid the errors I mentioned.
If you try to use favorite color as if it was color, forgetting about the possibility of null, Dart will tell you.
this makes your code safer.
（nullableであることを）明示的にしているので、Dartは私が先程挙げたエラーを回避するのを助けてくれます。
nullの可能性を忘れて好きな色をあたかも色であるかのように使おうとすると、Dartが教えてくれます。
このことによって、あなたのコードはより安全になります。
What's more, Dart's null safety is sound.
When Dart determines that a variable is non-nullable, that variable is always non-nullable.
Many other programming languages have unsound null safety, and in many cases still need to perform runtime checks.
Dart shares sound null safety with Swift, but not very many other programming languages.
Because of sound null safety, Dart can optimize your code to run faster.
So it's not just safer, it's also faster.
さらに、Dartのnull safetyは健全です。
Dartは変数がnull不可であると判断すると、その変数は常にnull不可になります。
他の多くのプログラミング言語には、健全ではないnull safetyがあり、多くの場合、実行時のチェックを行う必要があります。
DartはSwiftとsound null safetyを共有していますが、他の多くのプログラミング言語とは異なります。
sound null safetyのおかげで、Dartはコードを最適化して高速に実行することができます。
つまり、安全性が高いだけでなく、高速化も可能なのです。
What does all this mean for you, the developer?
As I said in the beginning, most variables always have some kind of value and never have no value.
In other words, they are non-nullable, which is a fancy way of saying they can't have null in them.
Therefore, most of your code should look like this -- no question marks, no null checks, nothing.
これは開発者のあなたにとって何を意味するのでしょうか？
冒頭で述べたように、ほとんどの変数は常に何らかの値を持ち、値がないことはありません。
言い換えれば、それらは nullを持つことができないということです。
したがって、あなたのコードのほとんどは次のように(クエスチョンマークもnullチェックもなにもない)なるはずです。
When you expect a variable to be potentially null, then you must explicitly mark it as nullable.
You do that with the question mark.
This doesn't just apply to variable declarations, but also to function arguments, function returns, generic types, and so on.
変数がnullになる可能性がある場合は、明示的にnullableであることを示さなければなりません。
これはクエスチョンマーク（?）で行います。
これは変数の宣言だけでなく、関数の引数、関数の戻り値、汎用型などにも適用されます。
Dart will then help you avoid null-related errors.
Basically it will ask you to add null checks where appropriate, and deal with a null that you might have forgotten about.
Dartは、null関連のエラーを回避するのに役立ちます。
基本的には、必要に応じてnullチェックを追加し、忘れていたかもしれないnullを処理するように教えてくれます。
What about the in-between situations though?
If you're assigning a non-nullable variable to a nullable field, that's OK.
A color that's always a color and never null can be accepted by a function that expects either a color or null.
しかし、その中間の状況はどうでしょうか？
nullableではない変数をnullableなフィールドに代入しているのであれば問題ありません。
常に色であり、決してnullではない色は、色かnullのどちらかを期待する関数に受け入れられます。
The other way around is trickier.
A nullable color, which can be a color or null, cannot be given to a function that expects a non-nullable color.
Said differently, if your function says, I never take nulls, my argument is non-nullable,
you can't give it something that might be null.
逆の場合はより厄介です。
色であってもnullであってもよいnullableな色は、nullableではない色を期待する関数には与えられません。
別の言い方をすると、もしあなたの関数が「私はnullを取らない」と言った場合、その引数はnullableではありませんので、nullかもしれないものを与えてはいけないのです。
So how do you deal with that situation?
You have a few possibilities.
One, avoid the call altogether if you know it's null.
Two, use some other value instead when you know it's null.
Three, force a nullable with an exclamation mark.
That's similar to writing a null check and throwing an exception if it fails.
So you should only do this if you're 100% sure the variable is not null in this particular case, even though the type is nullable.
For example, you may know something about your program's domain that Dart cannot possibly know.
Suffice to say, you should avoid the exclamation mark as much as possible.
それでは、その状況にどう対処するのか？
いくつかの可能性があります。
1つは、nullであることがわかっている場合は、その呼び出しを完全に避ける。(if文)
2つ目は、nullであることがわかっている場合は、他の値を使用する。（??）
3つ目は、感嘆符で強制的にnullableな値を指定する。（!）
これは、nullチェックを書いて失敗したら例外を投げるのと似ています。
ですから、型がnullableであっても、この場合は変数がnullではないと100%確信している場合にのみ行うようにしてください。
例えば、プログラムのドメインについて、Dartが知ることができない何かを知っているかもしれません。
感嘆符は可能な限り避けるべきです。
There you have it.
Null safety makes your code safer and even makes it run faster with minimal impact on how you write it.
Dart is smart enough in its analysis to let you do things without too much null-related boilerplate, but doesn't let you introduce null reference backs.
That's it for this video.
It was a mere introduction.
Check out dart.dev/null-safety for more.
And stay null-safe out there.
これでお分かりでしょう。
null safetyはコードの安全性を高め、書き方への影響を最小限に抑えながら、コードの実行速度を向上させます。
Dart は、nullに関連したあまり多くの決まり文句を使わずに実行できるように、解析を賢くしていますが、null参照バックを導入することはできません。
このビデオは以上です。
ほんの導入でした。
詳しくは dart.dev/null-safety をご覧ください。
そして、null-safeをよろしくお願いします。
合わせて読みたい