気づけば明日はクリスマスイブ
一応、参加予約分としては最後の投稿になります。

Qiitaのアドベントカレンダーとしては初参加でしたが、誰かのお役に立てていれば幸いです。
また、予想はしていましたが、過疎化の顕著なCodeigniterのアドベントカレンダーに19件も投稿頂いている@kenjisさんには感謝しております。
本当にありがとうございます。
実は私の入り口、Codeigniter2 時代から記事を拝見しており、@kenjisさんの記事がなかったら私はCodeigniterを今も使っていなかったかもしれません。

さて、Codeigniter4の記事としてはもうほとんどネタ切れのため、いっそ私のCodeigniter経歴とか開発環境でも載せようかどうしようか悩みましたが、正直それでは誰の役にも立たず趣旨がブレるので、今回は1記事にするほどでもないけど、私なりのTipsというか利用方法をまとめようと思います。

※ほとんど当たり前のようなことですが

設定ファイルは .env か constants.php か

要するに定数設定をどこに持つか、ということだが、Codeigniter3以前から利用していて、かつ他のFWをあまり触らない私のような人は後者に慣れていて、環境を揃える意味でもconstants.phpに殆どの設定を書いてしまいがち。
だが、Git等バージョン管理システムを利用する際にconstants.phpをgitignoreに書くのはちょっと面倒なので、私は以下のように使い分けている。

環境（ENVIRONMENTやインストールパス）ごとに変わるものは .env
- 例： DB設定、絶対パスやURLの設定など
すべての環境で共通のものは constants.php
- 例：相対パスやページネーションの定数（1ページに何件表示するみたいな）など

なお、Codeigniter4をインストールすると標準で.envはgiignoreに記載されている。

ここまで書いておいて何だが、私はパスやURLの設定もconstants.phpに書いてしまっている。
1つのCodeigniterで複数サイト（例：フロントと管理画面）を運用するを実装するのにあたって、.envではやりにくいことが多かったため。
そのため、ENVIRONMENTごとに別途ファイルを用意してNodeJS(Webpack）でconstatns.phpに吐き出すような運用をしている。

ENVIRONMENT = testing は使いにくい

CI_ENVIRONMENT = testing を設定すると、DB設定は database.tests を読みに行く
Codeigniter起動時にセッションがクリアされる
その他大量の制約がある
詳しくは system内をtestingで検索してみると良い（私も把握しきれていない）

特にログインを利用するシステムでは使いづらい。
Codeigniter3以前と同じ感覚で利用するとドツボに嵌るので注意。
テスト環境は CI_ENVIRONMENT = development にする。（productionでも良いが）

ヘルパやライブラリのオーバーライドに MY_ は不要

これもCodeigniter3以前のユーザーが対象。
名前空間を利用する事になったため、ファイル名は対象クラスのファイル名と同名でよい。
例えば、 form_helper を上書きするのは app/Helpers/form_helper.php となる。

var_dump なんて不要、便利なツールバー

development環境ならば画面下にすべてのデバッグデータが表示されている。

場所	内容
矢印アイコン	クリックすると画面上部へ移動する（上部にあれば下部へ）
ギアアイコン	ダークモード、ライトモード切り替え
グラフアイコン	処理時間と使用メモリ（プログラムのコストがわかる）
Dababase	DBログ（すべての実行クエリ）
Views	ロードしたView（ページ内にも対象エリアが表示される）
Files	ロードしたすべてのファイル
Events	実行されたイベントとコスト
History	アクセスログ（リダイレクトを含む、20件まで、app/Config/Toolbar.php から変更可能）
Vars	Viewに渡された変数のダンプ
Codeigniterアイコン	環境情報
xアイコン	最小化（右端にアイコンのみ表示になる）

レイアウト（CSS）によってはコンテンツにかぶってしまう可能性があるので注意。
上部移動や最小化で問題ないとは思うが、ツールバーが不要ならapp/Config/Filter.phpからToolbar二箇所をコメントアウトする。

開発環境でデバッグのためにvar_dumpやecho getLastQueryをする必要がなく、うっかり本番へ表示するリスクも減らせる。
ただし、本番環境をproductionにすることは絶対に忘れないこと。
そのためにも最初で触れた.envとconstants.phpをうまく使う。（サーバー側で設定するのが一番安全だが）

モデルの標準機能でDBを利用するためにはプライマリーキーが必要

ドキュメントに記載があるが、モデルを使ってDBを利用するにはプライマリーキーを設定しておく必要がある。
多対多や頻繁に書き換わるテーブルに設定するのは躊躇われるが、パフォーマンスにシビアでなければ、とりあえず bigintのunsignedでも設定しておくといいかも。

モデルでrequestを利用したい

モデル内でバリデーションしたり、IPやUAをDBに保存する場合に利用する。

$request = \Config\Services::request();
$postData = $request->getPost('hoge');  // $_POST['hoge']の受け取り
$ip = $request->getIPAddress() // $_SERVER['REMOTE_ADDR']の受け取り

モデルのstaticメソッドでDBを利用したい

// モデルの機能を利用するなら
$db = new self();
$db->find(1);

// DBコネクションを呼び出す
$db = \Config\Database::connect();
$db->table('hoge')->where('key', 1)->get();

私はビュー内で1度だけ呼び出すようなときによく使う。

app/Views/hoge.php

// 例えばドロップダウンリストの選択肢
echo form_dropdown('fuga', \App\Models\fugaModel::getSelections());

なお、前者はnewしていることからも分かる通り、構築中のクエリビルダの邪魔をしないのでControllerで利用するときも極稀に役立つ。

以上、少しでもお役に立てたら幸いです。
もし何か要望があれば最終日にでも付け足そうかと思います。
それでは、良いCodeigniterライフを！